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Pre  face 


The  purpose  of  this  thesis  was  to  build  a  tool  that 


would  integrate  the  use  of  structured  analysis  diagrams  with 


data  dictionaries  for  doing  software  requirements  analysis. 


Separate,  these  two  approaches  are  time  consuming  and 


involve  a  large  duplication  of  effort.  Using  the  tool,  the 


duplication  of  effort  is  removed,  thus  improving  the 


analyst’s  productivity. 


The  tool  was  designed  to  provide  the  graphical 


capabilities  needed  to  create  the  diagram  in  addition  to 


capabilities  to  enter  the  remaining  data  dictionary 


information.  Data  dictionary  information  may  be  transferred 


to  and  from  a  relational  database  that  stores  the  entire 


project  dictionary, 
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T.  Introduction 


General  Issues 

This  research  effort  was  part  of  the  continuing 
research  in  the  field  of  software  development  conducted  at 
the  Air  Force  Institute  of  Technology  (AFIT)  by  the 
Department  of  Electrical  and  Computer  Engineering.  In 
conjunction  with  this  research,  the  department  has 
established  documentation  standards  to  support  the 
requirements  analysis  phase  of  the  software  life  cycle.  The 
documentation  includes  structured  analysis  diagrams  and 
data  dictionaries.  The  structured  analysis  diagrams  use  a 
syntax  derived  from  Structured  Analysis  and  Design  Technique 
(SADT)  (SADT  is  a  trademark  of  SofTech,  Inc. ) 

Two  past  theses  led  to  the  concept  of  integrating  the 
structured  analysis  and  data  dictionary  documentation 
standards.  In  1984,  an  AFIT  thesis  by  Charles  W.  Thomas 
suggested  data  dictionary  information  could  be  obtained  from 
graphic  pictures  (Thomas,  1984:11).  In  1986,  an  AFIT  thesis 
by  Jeffrey  W.  Foley  developed  a  data  dictionary  editor  for 
the  Zenith  7.-100  computer  (Foley,  1986:3).  This  editor  is 
capable  of  creating  and  editing  data  dictionary  information 
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and  putt  ing  the  information  into  a  database  which  is  stored 
on  a  central  computer  system. 

This  project  is  a  direct  follow  on  to  the  1986  thesis 
by  James  W.  Urscheler.  He  created  an  initial  version  of  a 
tool  (nicknamed  RADD  for  Requirements  Analysis  tool  with 
Data  Dictionary)  that  allows  a  user  to  interactively  create 
and  edit  structured  analysis  diagrams  while  extracting  data 
dictionary  information  from  the  diagrams  (Urscheler, 

1986:3).  By  integrating  these  techniques  into  one  tool,  the 
software  analyst’s  work  is  reduced  when  creating  data 
dictionaries  and  structured  analysis  diagrams. 

In  conjunction  with  this  effort,  another  thesis  was 
conducted  to  design  a  central  database  that  will  standardize 
the  data  formats  for  software  engineering  tools  (Connally, 
1987).  Thus,  a  criterion  for  this  thesis  was  to  develop  a 
data  format  capable  of  interfacing  to  this  central  database 
as  well  as  storing  complete  data  dictionary  information  and 
structured  analysis  graphics  information. 

Background 

SADT.  SADT  is  the  name  of  SofTech’s  methodology  for 
doing  requirement  analysis  and  system  design.  It  was 
first  published  in  1977  by  Douglas  T.  Ross  of  Sof'Tech  (Ross, 
1977).  The  methodology  was  found  effective  when  applied  to 
"a  wide  range  of  planning,  analysis,  and  design  problems 


involving  men,  machines,  software,  hardware,  database, 


& 


« 


communications  procedures  and  finances  ..."  ( lioss ,  1977:17 


SADT  provides  techniques  and  methods  for: 


% 

.V 


thinking  in  a  structured  way  about  large  and 
complex  problems; 


V" 


2.  communicating  analysis  and  design  results  in 
clear,  precise  notation; 


v 

Si 


3.  controlling  accuracy,  completeness,  and 
quality  by  procedures  for  review  and  approval ; 

4.  documenting  the  system  analysis  and  design 
history,  decisions,  and  current  results; 

5.  working  as  a  team  with  effective  division  and 
coordination  of  effort;  and 

6.  managing  development  projects  and  assessing 
progress  (Softech  Inc.,  1977:1-1). 

An  SADT  model  consists  of  diagrams  drawn  according  to 
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a  well  defined  graphical  syntax.  Each  diagram  has 

accompanying  text  to  assist  in  the  understanding  of  the 

diagram.  The  diagrams  represent  a  hierarchical  outline  of 

the  system.  According  to  Softech 

Each  lower- level  diagram  shows  a  limited  amount  of 
detail  about  a  well-bounded  subject.  Further,  each 
diagram  connects  exactly  into  the  model  to 
represent  the  whole  system,  thus  preserving  the 
logical  relationship  of  each  component  to  the  total 
system  (Softech  Inc.,  1976:2-6). 

Figure  1  is  an  example  of  an  AFTT  SADT  type  diagram.  SADT 

models  all  systems  in  terras  of  the  system  happenings,  or 

activities,  and  the  system  objects,  or  data  (Softech  Inc., 

1976:2-5).  Softech  SADT  methodology  calls  for  the 
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decomposing  of  both  the  activities  and  the  data 


independently  of  each  other  (Ross,  1977:19). 

The  language  used  to  construct  both  types  of  SADT 
diagrams  consists  of  40  graphical  type  features  and 
principles.  The  language  has  two  components:  English  text 
and  graphical  constructs.  Combining  the  two  components 
provides  the  function  needed  to  provide  communication  (Ross 
1977 : 19)  . 

The  graphical  language  is  designed  to 

1.  expose  detail  gradually  and  in  a  controlled 
manner ; 

2.  encourage  conciseness  and  accuracy; 

9.  focus  attention  on  module  interfaces;  and 

1.  provide  a  powerful  analysis  and  design 
vocabulary  (Softech  Inc.,  1976:2-6). 


Rectangular  boxes  and  arrows  are  the  primary  graphical 

constructs  used  in  making  an  SADT  diagram.  The  boxes 

represent,  the  decompositions  of  the  parts  of  the  system. 

Arrows  are  used  to  describe  how  the  boxes  interface  between 

each  other  on  the  diagram.  English  text  is  used  to  label 

the  boxes  and  the  arrows  and  define  their  meaning  (Softech 

Inc.,  1976:4-4).  According  to  the  Softech  definition 

Input  data  (on  the  left  of  the  box)  are  transformed 
into  output  data  (on  the  right)  by  the  activity 
represented  by  the  box.  Controls  (on  the  top) 
govern  the  way  the  transformation  is  done  (Softech 
Inc . ,  1976 : 4-5 ) . 

Arrows  do  not  represent  a  flow  of  control ,  rather,  the 
describe  classes  of  data.  One  arrow  can  represent  several 


classes  of  data;  this  is  referred  to  as  a  pipeline.  The 
label  for  the  arrow  must  precisely  describe  the  contents  of 
the  pipeline  (Softech  Inc.,  1976:4-7). 

Applying  the  SADT  methodology  allows  teams  to 
effectively  work  together.  As  part  of  the  process,  the 
authors  distribute  drafts  of  the  SADT  diagrams  and 
supporting  documentation  to  interested  parties.  This 
process,  ('ailed  a  peer  review,  permits  the  parties  to  review 
the  drafts  and  make  written  comments  to  the  authors.  The 
author  then  responds  to  these  comments.  This  process 
continues  until  all  agree  that  the  model  is  complete. 

The  reader  is  referred  to  the  1977  article  by  Douglas  T 
Ross  for  a  more  definitive  description  of  the  SADT  concept 
(Ross,  1977). 

IDEFq .  The  U.  S.  Air  Force  Program  for  Integrated 
Computer  Aided  Manufacturing  (ICAM)  adopted  a  structured 
graphic  technique  called  IDEFg  (ICAM  Definition  Method 
zero).  IDEFq  is  a  derivative  of  SADT,  tailored  by  Softech, 
Inc.  for  ICAM.  It  is  the  function  modeling  technique 
applied  to  all  ICAM  projects  (Smith,  1981:1).  IDEFq  was 
developed  to  give  a  structured  approach  to  applying  computer 
technology  to  manufacturing  and  to  enhance  the  communication 
and  analysis  of  the  people  involved  in  improving 
manufacturing  productivity.  A  detailed  comparison  of  the 
SADT  and  lDKFn  syntaxes  is  found  in  Appendix  A. 
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Data  Dictionaries.  The  purpose  of  a  data  dictionary 
is  to  manage  and  document  a  valuable  resource,  data.  Using 
a  data  dictionary  system  properly  provides  measurable 
benefits  to  an  organization  (Lefkovits,  1977).  Ten  areas 
that  benefit  from  an  effective  data  dictionary  system  are 
1  i sted  be  1 ow . 

1.  Reduction  of  data  redundancy 

2.  Reduction  of  system  development  costs 

3.  Enhancement  of  the  system  maintainability 

4.  Improved  impact  of  change  assessments 

5.  Enforcement  of  data  standards 

6.  Improved  information  for  data  base  creation 

7.  Improved  Communication  between  people 

8.  Better  auditing  of  use  of  data 

9.  Reduction  of  Administrative  Effort 

10.  Creation  of  trustworthy  information  (Lefkovits, 
1977:1-8  thru  1-11) 

The  AFIT  methodology  for  including  data  dictionaries 
wit.h  the  requirements  analysis  is  supported  by  Leong-Hong  and 
Plagman.  They  said, 

The  use  of  the  DD/DS  (data  dictionary/directory 
system)  in  requirements  definition  and  analysis  is 
critical.  The  DD/DS  provides  a  framework  in  which 
the  end-user  and  the  analyst  can  communicate  with 
each  other  using  common  terminology  and 
definitions.  Communication  between  the  end-user 
and  the  analysts,  between  the  analyst  and  the 
designer,  and  between  the  designer  and  the 
developer  is  essential  in  building  a  system.  By 
maintaining  consistency  in  the  data  used, 
potentially  disastrous  conditions  caused  by 
inexact  or  inconsistent  data  can  be  averted 
(Leong-IIong  and  Plagman,  1982:34  ). 

Leong-Hong  and  Plagman  identified  yet  another  benefit, 
that  the  data  dictionary  gives  the  requirements  analyst,  that, 
of  maintaining  documentation.  The  data  dictionary  maintains 
desc r i pt i ons  of  the  activities  and  data  needed  for  each 


activity.  From  these  descriptions,  documentation  regarding 
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the  effect  of  activities  upon  each  other  is  readiLy  available 
(I.eong-Hong  and  Plagman,  1982:41-43).  The  authors  further 
recommend  an  automated  data  dictionary  system  for  producing 
documentation  to  reduce  the  monotony  and  repetitiveness  of 
the  task  (Leong-Hong  and  Plagman,  1982:50). 

St at oment  of  the  Problem 

The  purpose  of  this  thesis  was  to  integrate  the 
structured  analysis  and  data  dictionary  techniques  into  a 
CAD  tool  to  attempt  to  make  the  software  requirements 
analyst’s  job  more  efficient. 

Scope 

To  make  RADD  useful,  the  requirements  and  design  of  the 
RADD  prototype  were  analyzed  to  ascertain  the  changes  and 
additions  needed.  The  software  to  effect  the  changes  was 
designed,  coded,  and  tested,  and  the  usefulness  of  the  new 
version  of  RADD  was  established  by  a  formal  evaluation  using 
questionnaires  and  statistical  analysis  of  the  responses. 

Assumpt i o ns 

For  the  purposes  of  this  thesis,  the  researcher  made 
four  assumptions.  These  assumptions  are  listed  below. 
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1  .  The  users  of  this  tool  are'  AFIT  graduate 
students  and  faculty. 

2.  The  users  of  this  tool  are  competent,  in  the 
use  of  computers. 

3.  The  users  of  this  tool  are?  familiar  with  t.he 
structured  analysis  methodology  and  uses  of 
data  dictionaries. 

4.  The  requirements  analysis  methodology  used  is 
described  in  AFIT’s  Software  Development. 
Documentation  Guidelines  and  Standards 

(  Hart,  rum  ,  1986:8)  . 

Research  Approach 

This  research  was  accomplished  in  three  phases.  In  t.he 
first  phase; ,  the  current  requirements  analysis  for  RADD  was 
reviewed,  followed  by  a  review  of  the  design  and 
implementation  of  RADD.  These  were  updated  and  changed  as 
necessary  to  reflect  the  new  requirements  and  design  of  the 
new  tool.  Next,  the  reusable  parts  of  the  RADD  software 
were  extracted  and  new  code  written  to  implement  the  changes 
deemed  necessary  by  the  analyses.  Finally,  an  evaluation  of 
the  new  tool’s  usefulness  to  a  software  analyst  was 
accompl  i shed  . 

Part  of  the  first  phase  was  to  review  the  requirements 
analysis  for  RADD.  This  was  necessary  because  the  initial 
version  of  RADD  needed  improvements  to  become  useful; 
therefore,  requirements  for  the  initial  version  of  RADD  were 
not  complete.  The  requirements  analysis  for  RADD  was 
described  textual ly  in  Chapter  Three  and  graphically  by 
structured  analysis  diagrams  in  t.he  Appendix  of  the 
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Urscheler  thesis.  In  performing  this  analysis,  it  was 
necessary  to  analyze  other  structured  analysis  methodologies 
to  define  a  suitable  language  for  the  AFIT  environment. 

From  this  language,  a  minimum  subset,  for  the  new  structured 
analysis  tool  was  identif  ed. 

Also  during  the  first  phase,  the  design  and 
implementation  of  RADD  was  analyzed.  This  was  necessary 
because  RADD  was  not  completely  useful.  For  instance,  in 
addition  to  expanding  the  language  implemented  by  RADD,  it 
was  necessary  to  permit  printing  hard  copies  of  the 
structured  analysis  diagrams.  Furthermore,  design  issues 
such  as  extensibility  and  maintainability  were  considered. 

The  design  of  the  database  was  examined  with  regards  to  the 
central  database  management  system  being  designed  for  the 
AFIT  distributed  design  environaient.  After  completing  these 
analyses  and  identifying  the  necessary  enhancements,  the 
second  phase  began. 

Th  e  second  phase  was  the  development  of  the  software. 
Using  a  top-down  approach,  the  modules  were  coded  and  tested, 
integrating  the  system  in  the  process.  All  software 
conformed  to  the  standards  set.  forth  in  AFIT’s  Software 
Revel  opine  nt  Doe  ume  n  ta  t  j  on  fiuidel  ines  and  Standards  pamphlet 
( Mart  rum ,  1 986  )  . 

The  third  phase  was  a  formal  evaluation  of  the 
structured  analysis  tool's  usefulness  to  a  software  systems 
analyst.  A  likely  pool  of  analysts,  f am i  1  i a r  with 
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structured  analysis  and  data  dictionaries,  was  drawn  from 
the  students  and  faculty  of  AFIT’s  software  engineerin),' 
classes.  These  people  were  polled  using  standard 
questionnaires  (Foley,  1986).  The  results  of  these 
questionnaires  were  compiled  and  analyzed  with  statistical 
methods,  establishing  the  tool’s  usefulness  to  the  AF1T 
software  systems  analyst.. 

Fqu  i  x>me  nt  and  Software 

The  equipment  and  software  for  this  thesis  were 
available  in  the  Information  Systems  Laboratory  of  the  AF1T 
Department  of  Electrical  and  Computer  Engineering.  The 
computer  used  for  this  thesis  is  the  Sun  3  (Sun  is  a 
trademark  of  Sun  Microsystems  Inc.)  workstation.  This 
workstation  runs  Berkeley  UNIX  (UNIX  is  a  trademark  of  AT&T ) 
version  4.2  and  features  Suncore  graphics  and  the  Sunwindow 
environment.  The  software  developed  in  this  thesis  was 
writ  ten  in  C . 

Seq  lie  nee  of  Presen  tat  i  on 

This  thesis  consists  of  six  chapters.  A  literature 
review  of  human/computer  interface  issues  is  presented  in 
Chapter  II.  The  requirements  for  the  new  tool  are  presented 
in  Chapter  III.  The  system  design  is  presented  in  Chapter 
IV.  Chapter  V  is  a  summary  of  the  implementation  and  is  a 
st  at  ist  i  cal  analysis  of  user  reaction  t.o  the  tool  .  Chapter 
V' I  presents  the  researcher’s  conclusions  and  reeommendat  ions. 
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II.  Review  of  the  Literature 


I  nt.roduction 

The  purpose  of  this  thesis  effort  was  to  build  an 
interactive  CAD  tool.  It  was  imperative  that  the  researcher 
understand  the  issues  that  impact  interactions  between  the 
computer  and  the  user.  Since  the  human/computer  interface 
issues  were  deemed  critical  to  the  success  of  this  effort,  a 
review  of  the  literature  was  conducted  to  gain  the  knowledge 
needed  to  design  the  human/computer  interface  for  this  tool. 

Iluman/Computer  Interface 

A  computer  system’s  effectiveness  is  directly  related 
to  how  well  the  user  and  the  computer  are  able  to 
communicate  with  each  other.  Newman  and  Sproull  noted  it  is 
the  design  of  this  user  interface  that  "...  has  a 
particularly  strong  impact  on  the  program  acceptability  as  a 
whole”  (Newman  and  Sproull,  1979:443).  The  importance  of 
the  human/computer  interface  was  further  amplified  by  Robert 
W.  Bailey.  He  said: 

Not  considering  human  performance  in  the 
human/computer  interface  frequently  results  in 
large  numbers  of  errors,  requires  huge  amounts 
of  training  time,  and  causes  user  frustration 
and  dissatisfaction  (Bailey,  19S2:293). 

Because  each  user  has  a  different  background  and 

experience,  the  process  of  designing  t.he  user  interface  is 

difficult.  This  is  further  complicated  because  a 
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universally  accepted  aethod  for  designing  a  huaan/coiputer 
interface  does  not  exist  (Woffinden,  1984:15-16).  As  Foley 


and  Van  Daa  noted 

Like  architecture,  the  design  of  user  interfaces 
is  at  least  partly  an  art  rather  than  a  science. 

We  hope  that  the  design  of  user  interfaces  will 
soaeday  becoae  aore  science  than  art,  but  the 
cliab  to  reach  this  goal  is  long;  the  ascent  has 
begun,  but  there  are  aany  hard  traverses  ahead 
(Foley  and  Van  Du,  1982:217). 

User  Interface  Coaponents.  Newman  and  Sproull  (Newaan 
and  Sproull,  1979:445)  divided  the  user  interface  into  four 
coaponents.  Figure  2  enuaerates  these  coaponents.  Since 
the  naaes  of  the  coaponents  do  not  iaply  their  full  aeaning, 
a  short  discussion  of  each  follows. 


Figure  2.  Coaponents  of  the  User  Interface 


The  user’s  aodel  is  "the  conceptual  aodel  foraed  by  the 
user  of  the  inforaation  he  aanipulates  and  of  the  processes 
he  applies  to  this  inforaation"  (Newaan  and  Sproull, 
1979:445).  In  other  words,  it  is  the  way  the  user  thinks 
and  understands  the  prograa  to  work;  therefore,  he  is  able 
to  devise  his  own  strategies  for  operating  the  prograa. 
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Thus  a  good  user  model  is  characterized  by  the  user 
understanding  the  purpose  of  each  input  he  gives  the 
computer  rather  than  blindly  following  the  user’s  manual 
instructions.  The  user’s  model  should  present  objects  or 
phrases  that  are  familiar  to  the  user  and  simulate  the 
modeled  environment.  "The  use  of  familiar  concepts  makes 
the  user's  model  more  intuitive  and  easier  to  learn"  (Newman 
and  Sproull,  1979:448). 

Next,  the  user  needs  to  know  the  command  language  to 
use  t.he  model.  Designing  a  command  language  involves 
recognizing  that  all  commands  relate  to  each  other  and 
together  they  define  a  syntax  for  the  language.  In  addition 
to  syntax,  the  semantic  value  of  each  command  must  be 
cons i dered . 

Newman  and  Sproull  reported  there  are  four  issues  that 
f urther  co  mpl  icate  the  design  of  a  command  language.  These 
are 

1.  Command  modes.  Allowing  the  same  user  input 
to  be  interpreted  in  different  ways  depending 
on  the  current  mode. 

2.  Selection  sequence.  Usually  an  operation  must 
be  selected  in  addition  to  selecting  an  object 
to  operate  on.  Which  comes  first  has  an 
effect  on  the  number  of  command  modes. 

3.  Command  abort  mechanism.  Commands  requiring  a 
sequence  of  inputs  must  allow  for  retraction 
of  the  command  in  the  middle  of  the  sequence. 

1.  Error  handling.  It  must  be  decided  how  to 
handle  erroneous  or  meaningless  commands 
(Newman  and  Sproull,  1979:451-452). 


Another  dimension  to  the  user  interface  design 


complexity  is  the  number  of  possible  input  devices 
available.  The  designer  must  be  consistent,  by  making  the 
user  operate  the  same  input  device  for  each  command. 

Feedback  is  required  to  let  the  user  know  what  is  going 
on  in  the  program,  and  should  be  given  quickly.  According 
to  Newman  and  Sproull,  three  important  forms  of  feedback  are 

1.  Feedback  by  informing  the  user  if  a  command 
ha  s  been  accepted,  or  if  an  error  has 
occurred . 

2.  Feedback  that  the  correct  object  has  been 
selected . 

3.  Feedback  such  as  cursor  feedback,  character 
echoing,  and  so  forth  (Newman  and  Sproull, 

1979 : 464 ) . 

Information  display  is  the  final  component  of  the  user 
interface.  The  flexibility  given  designers  by  graphical 
devices  poses  a  problem  in  determining  an  effective  means  to 
display  the  information.  These  problems  have  fallen  into 
two  categories:  overall  layout  and  representation  of 

objects.  Screen  space  is  usually  at  a  premium  and  what  is 
pertinent  for  display  at  a  given  time  must  always  be 
evaluated.  On  the  other  hand,  if  user  controlled  windows 
compose  the  display,  the  burden  of  arranging  the  display  can 
be  shifted  to  the  user  (Newman  and  Sproull,  1979:160). 

Newman  and  Sproull  further  suggested  that  the  quality 
of  the  graphic:  display  forces  the  designer  to  make  trade¬ 
offs.  The  designer  must  decide  between  the  amount  of  screen 
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space  taken  and  the  amount  of  detail  necessary  for  a  given 


image  (Newman  and  Sproull,  1979:462). 

After  studying  the  components  of  the  human/computer 
interface,  various  general  user  interface  design  principles 
were  researched. 

Design  Principles.  As  previously  stated,  a  universally 

acceptable  method  for  designing  a  human/computer  interface 

does  not  exist;  however,  experience  has  led  to  the 

documentation  of  certain  design  principles.  Figure  3  is  a 

list  of  principles  by  four  different  authors  for  designers 

of  interactive  programs.  It  should  be  noted  the  principles 

encompass  all  four  components  of  the  user  interface.  Also, 

the  list  given  by  D.  S.  Woffinden  was  derived  from  works 

including  those  of  the  other  three  authors  on  the  list. 

Woffinden  found  these  guidelines  incomplete.  He  said: 

None  of  the  lists  of  general  design  guidelines 
studied  were  found  to  be  completely  satisfactory. 

Many  seem  to  have  become  over  concerned  with  the 
human  issue  and  seem  to  fall  short  of  giving 
guidance  revelant  [sic]  to  the  complete  design 
process  for  an  interactive  system  (Woffinden, 

1984: 19) . 

Figure  3  shows  that  each  author  views  human/computer 
design  from  a  slightly  different  perspective.  Nonetheless, 
Foley  and  Van  Dam  asserted  it  is  important  for  the  designer 
to  consider  these  design  principles  if  a  satisfactory 
interface  is  to  result  (Foley  and  Van  Dam,  1982:218). 
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I  n  t er fac i ng  wi t h  a  Mou s e 

Increasing  the  number  of  different  input  devices 
increases  the  design  complexity.  Since,  in  this  project, 
the  mouse  and  the  keyboard  were  used  for  input,  it  was 
important  to  consider  the  issues  surrounding  human/computer 
interfacing  with  a  mouse. 

Lynne  A.  Price  considered  it  practical  to  use  a  mouse 
in  CAD  programs  because  of  the  following  six  advantages: 


1.  Mice  allow  control  of  the  cursor  through  arm 
motion  natural  to  pointing. 

2.  A  mouse  gives  the  user  the  ability  to  point 
and  to  invoke  several  functions  with  one  hand. 

3.  The  mouse  allows  cursor  position  to  be 
controlled  by  software  somewhat  independently 
of  the  user’s  hand  motion. 

4.  The  mouse  permits  the  user  to  remove  his  hand 
from  the  pointing  device  (e.g.,  to  use  the 
keyboard  or  answer  the  telephone)  with  no 
change  in  the  cursor  position  on  the  screen. 

5.  The  pads  required  by  optical  mice  are  light, 
are  easily  moved,  and  may  be  placed  on  top  of 
normal  desktop  clutter. 

6.  Mice  are  convenient  for  both  left  and  right 
handed  users  (Price,  1984:288). 

Price  conducted  four  experiments  to  test  the 
suitability  of  the  mouse  as  a  pointing  device  for  CAD 
systems.  The  experiments  involved  pointing  the  cursor  with 
the  mouse  at  graphic  items  and  clicking  the  buttons.  A 
mechanical,  three  button  mouse  was  used  for  the  first  three 
experiments  (Price,  1984:288-293). 


The  first  experiment  tested  forty-two  individuals 


abilities  to  use  the  buttons  and  control  the  cursor 
position.  Errors  occurred  more  frequently  when  the  number 
of  buttons  involved  increased  and  when  the  mouse  was  moved 
while  buttons  were  held  down  (Price,  1984:289). 

Th  e  second  experiment  attempted  to  determine  if 
different  numbers  of  clicks  of  a  single  button  or  use  of  a 
different  button  to  indicate  the  same  input  decreased 
accuracy  and  caused  more  errors.  No  significant  difference 
was  observed  in  the  time  to  complete  comparable  experiments 
or  in  the  accuracy  between  the  two  methods  (Price, 

1984:290) . 

The  third  experiment  attempted  to  determine  if  the 
decrease  in  performance  noted  in  the  previous  experiment  was 
function  of  the  time  allowed  the  user  to  begin  the  second 
click.  In  experiment  two,  the  people  were  required  to  enter 
the  second  click  within  a  half  to  three-quarters  second  of 
the  first  click.  In  this  experiment,  this  delay  was  varied 
up  to  one  half,  three-quarters,  and  one  full  second.  Price 
found  as  the  delay  time  was  increased,  the  difference  in 
performance  became  less  significant  (Price,  1984:291). 

In  the  final  experiment,  a  different  style  of  mouse  was 
tested,  one  with  two  horizontal  rocker  buttons  providing 
four  distinct  inputs.  No  significant  difference  in 
performance  or  accuracy  was  identified  for  any  for  the 
variations  tested;  however,  a  large  majority  preferred  the 
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variation  that  most  closely  simulated  the  previous  style  mouse 
Price  concluded  that  people  prefer  using  one  finger  for  each 
different  input  and  that  a  mouse  with  vertically  configured 
buttons  is  preferred  (Price,  1984:292). 

Overall,  Price  concluded  the  differences  in  performance 
and  accuracy  identified  in  the  four  experiments  were  small 
enough  to  justify  using  more  complicated  input  techniques 
when  the  number  of  different  inputs  exceeded  the  number  of 
available  buttons.  She  also  noted  these  more  complicated 
techniques  would  cause  a  large  software  overhead  for  the 
designer  by  requiring  a  check  for  multiple  button  clicks  and 
by  requiring  a  check  for  user  input  errors  (Price, 

1984 : 293) . 

Summary 

The  purpose  of  this  literature  review  was  to  assimilate 
the  latest  information  that  pertained  to  the  interface 
between  a  computer  and  its  user.  Information  was  gathered 
to  review  the  components  of  the  interface  and  the  design 
principles  one  should  consider  when  constructing  a 
human/computer  interface.  Also,  because  the  tool 
constructed  by  this  thesis  effort  used  a  mouse  as  an  input 
source,  information  on  experiments  to  test  a  mouse’s 
suitability  for  the  tool  was  studied.  After  gaining  an 
understanding  of  these  critical  subjects,  the  researcher 


based  requirement  and  design  decisions  on  the  foundations 


learned  here. 


III.  REQUIREMENT  ANALYSIS  FOR  A 
STRUCTURED  ANALYSIS  TOOL 


The  issues  constraining  the  requirements  for  this  tool 
are  sorted  into  three  broad  categories.  The  categories  are 
available  hardware  support.,  available  software  support,  and 
existing  requirements  based  on  previous  studies.  After 
considering  these  constraints,  the  requirements  specific  to 
the  CAD  tool  are  identified. 

Hardware  Support 

Because  this  tool  is  to  be  integrated  into  the  AE'IT 
computing  environment,  it  is  necessary  to  consider  the 
restrictions  the  environment  poses  on  the  tool.  Currently, 
the  computing  environment  consists  of  several  mainframe 
computers  and  many  stand-alone  workstations.  The  primary 
mainframes  are  two  VAX  11/785  computers  (VAX  is  a  trademark 
of  Digital  Equipment  Corporation  Inc.)  running  the  Berkeley 
4.3  UNIX  operating  system. 

Access  to  the  mainframes  is  available  through  the  use 
of  the  AFITNF.T.  This  provides  the  capability  to  connect  to 
t.he  computers  with  a  home  computer  over  the  t.e  I  ephone  1  inos 
(AFIT/SI,  1987).  Also,  there  are  Zenith  Z-100  and  Z-248 
workstations  that  are  able  to  access  the  AFITNET.  The 
AFITNFT  gives  other  mainframes  and  the  SUN  (SUN  is  a 


trademark  of  SUN  Microsystems)  workstations  the  capability 


to  remotely  Login  to  the  11/785’s  via  an  Ethernet  cable. 


Software  Support 

As  discussed  further  in  the  next  section,  a  requirement 
already  existed  that  the  data  produced  by  the  tool  be  stored 
in  a  relational  database  using  the  INGRES  database 
management  system  on  a  UNIX  host  computer.  The  capability 
to  store  the  data  produced  by  the  tool  was  developed  in 
conjunction  with  t.h  i  s  thesis  effort.  Thus ,  there  was  a 
requirement,  that  the  software  create  data  files  usable  by 
the  relational  database  manager. 

The  software  used  to  create  the  tool  was  also  required 
to  interface  to  a  graphics  package.  In  the  interests  of 
portability,  the  use  of  a  standard  graphics  package  needed 
consideration.  Also,  the  software  needed  to  be  portable  to 
other  systems . 


Exist,  ing  Requirements  from  Previous  Studies 

Data  Dictionary  Editor.  This  computer  tool  permits 
users  to  create  and  edit,  data  dictionary  definitions  for  the 
requirements,  design,  and  coding  phases  of  the  software 
lifecycle.  After  editing  the  definitions  on  a  personal 
computer  type  workstation,  users  may  transfer  the 
definitions  to  the  database  host  via  the  AF1TNKT  using 


available  communications  software.  A  current  thesis 
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off  ort  will  make  i  t  pnss  i  b  1  e  to  store  the  definitions  in  the 
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cent  ral  database. 

The  data  dictionary  definitions  created  by  the  edit-ir 

and  the  tool  from  this  thesis  are  related.  Urscheler 

designed  the  prototype  in  this  manner.  lie  sail1: 

To  insure  there  is  a  level  of  consistency,  'he 
same  definitions  were  employed  i  n  RADI)  .  Ife 
consistency  resulted  i r  a  direct  link  he  I  weei  t  h  • 

7-  1  00  ed  i  t  or  and  RADI)  a  I  the  database  level 
!  I'rsehe  I  er  .  1  0 8 1.  :  19)  . 

Thu  the  requ  i  reme  n  t  to  maintain  consistency  at.  the  database 
lr\i‘l  s  *  i  I  I  existed  for  this  t.hes  i  s  effort. . 

Ilumari/(’«)inpu  t  er  Inter  face  Requ  i  reinen  ts  .  As  discussed  in 
Chapter  Two,  an  adequate  human/computer  interface  is 
•ri ticnl  to  the  success  of  interactive  computer  tools.  This 
t.hesis  effort  as  well  as  the  Ursoheler  effort  were  bound  by 
this  requirement,.  Figure  4  is  a  list  of  the  five  key 
psychological  factors  Urscheler  considered  in  attempting  to 
fulfill  the  human/computer  interface  for  his  effort. 

Analysis  of  the  RADD  human/computer  interface  by  this 
researcher  found  the  interface  a  good  one.  Overall,  the 
user  feels  a  real  sense  of  drawing  an  SA  (Structured 
Analysis)  diagram  when  using  RADD.  However,  enhancements  in 
areas  specified  by  the  requirements  in  Figure  4  are  needed 
to  improve  the  existing  human/computer  interface.  The 
requirements  presented  by  Urscheler  and  those  established  in 
Chapter  Two  were  considered  in  the  design  of  the  fol low-on 
too  1  . 
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Keep  the  user  motivated 
ho re  him. 


do  not  frustrate  or 


Break  the  lengthy  input  process  into  parts  to 
permit,  the  user  to  achieve  "psycholog  iral 
closure".  This  provides  positive  feedback  to 
the  user  through  a  feeling  of  accomplishment, 
and  success. 

Minimize  the  memorization  required  by  the 
user  . 

Provide  visually  pleasing  displays  on  the 
screen.  This  includes  minimizing  the 
scrolling  and  other  distracting  movements  of 
text,  the  highlighting  of  instructions  to  the 
user,  and  making  effective  use  of  margins  and 
wh i te  space . 

5.  Keep  response  time  to  a  minimum.  Display 

status  messages  to  keep  the  user  constantly 
informed  of  what  is  happening  inside  the 
mach i ne . 


Figure  4.  RADD  Human-Interface  Requirements 
Source:  (IJrscheler,  1986:21) 


Requirements  for  the  Follow-on  Tool 

In  defining  the  requirements  for  the  follow-on  tool,  i 
was  necessary  to  analyze  the  current  implementation  and 
determine  how  well  it  conformed  to  the  original 
requirements.  Areas  of  specific  interest  were  the 
human/computer  interface,  the  tool’s  functionality,  and  the 
reusability  of  the  software.  Also,  it  was  necessary  to 
evaluate  the  SADT  methodology  to  determine  the  requirements 
for  a  necessary  and  sufficient  SA  language  suitable  for  the 
AFTT  software  development  environment. 


Dt't.erm  i  n  i  ni'  how  wo  !  I  KADI)  complied  with  its 
requirements  was  difficult.  Being  a  prototype  and  given  t.h* 
t  ime  constraint  in  which  it  was  developed,  the  requirements 
analysis  did  not  measure  up  to  those  specified  in  the 
Software  Development.  Documentation  Guidelines  and  St.andards, 
The  given  requirements  analysis  was  not  decomposed  to  the 
level  of  det.ail  necessary  to  specify  all  t.he  activities  and 
dat  a  . 

RADD  implemented  a  smal  1  subset,  of  the  total  SADT 
language  needed  to  satisfy  the  AF1T  software  requi rements 
methodology;  therefore,  a  requirement  existed  t.o  define  an 
exact  language  syntax  for  the  tool.  If  possible,  it.  was 
desirable  t.o  develop  a  standard  consistent,  with  exist.ing 
standards  adopt. ed  by  the  Air  Force.  A  study  was  conducted 
to  determine  if  such  a  standard  existed  and  to  define  the 
syntax.  Appendix  A  discusses  the  results  of  the  study. 

In  addition  to  the  SADT  diagram,  requirements  existed 
t.o  produce  facing  page  t.ext.  for  the  diagram  and  data 
diet  ionaries  for  each  act  ivity  and  dat.a  element.  Format 
guidel inns  for  these  products  are  given  in  Software 
Development,  Documentation  Guidelines  and  Standards  . 

Appendix  A  also  presents  exact,  formats  for  each  of  these 
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This  I'hapt  er  dcsor  i  bed  the  requirements  for  a  graphical 
st  ruct  ureii  analysis  CAD  tool  .  The  requirements  based  on 
constraints  from  hardware  support,  software  support,  and 
previous  studies  were  discussed.  Also,  human/eomput.er 
interface  reipi  i  ri'inents  were  identified  and  discussed.  The 
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DESIGN  AND  DEVELOPMENT  OK  THE  SA  TOOL 


I  V  . 

In  the  previous  chapter,  specific  requirements  for  this 
tool  were  discussed  as  well  as  issues  constraining  the 
requirements.  The  purpose  of  this  chapter  is  to  present  the 
design  decisions  made  based  on  those  requirements  and  on  the 
objectives  of  the  thesis.  This  chapter  discusses  the  design 
considerations  taken  into  account  during  the  design  process, 
the  considerations  in  defining  the  internal  data  structures 
used,  the  definition  of  the  file  structures  used,  and  the 
approach  taken  to  the  coding  and  testing  of  the  tool. 

Hardware  Considerations 

The  SUN  workstat.  i  ons  were  chosen  because  they  met 
several  hardware  requirements.  First,  the  SUN  workstations 
are  linked  to  the  AFITNET.  This  integration  with  the  AFIT 
computing  environment  was  important  because  data  dictionary 
information  from  the  tool  is  stored  in  a  database  that  may 
be  maintained  on  another  machine. 

The  SUN  workstation’s  main  memory  is  adequate  for 
executing  the  tool’s  program.  Because  the  executable  file 
is  in  excess  of  1  Mbyte,  smaller  workstations  like  the  /.-100 
could  not  be  used. 

The  SUN  workstations  have  a  large  display  monitor  that 
accommodated  t.he  intended  screen  layout.  The  intended 
screen  layout  consisted  of  five  distinct  areas,  one  being 


the  drawing  area  that  had  to  be  Large  enough  to  clearly  show 
all  the  graphical  constructs  of  the  SA  syntax. 

The  SUN  workstations  provide  a  mouse  in  addition  to 
the  keyboard  as  an  input  device.  The  mouse  is  the  primary 
input  tool  for  selecting  and  manipulating  the  graphical 
constructs  on  the  SA  diagram  because  of  its  abiLity  to 
function  as  both  a  locator  and  a  pick  device. 

Finally,  the  SUN  workstations  are  sufficient  in  number 
and  meet  the  availability  requirement.  Currently,  there  are 
six  SUN  workstations  available  and  all  are  linked  to  the 
AFITNET. 

So  ftwa  r  e_  Conuderations 

Portability  was  considered  when  selecting  a  software 
graphics  package.  The  prototype  developed  by  Urscholer 
utilized  the  SunWindows  environment  (SunWindows  is  a 
trademark  of  Sun  Microsystems  Inc.).  At  the  time  the  tool 
implementation  began,  an  implementation  of  the  GKS  graphics 
standards  called  SunGKS  was  available  only  in  a  beta  version 
with  the  release  date  of  the  final  version  unknown.  Also  at 
implementation  time,  SUN  had  released  a  new  version  of 
SunWindows,  called  SunView.  Given  these  circumstances  and 
that  portions  of  Urscheler's  software  could  be  used,  it.  was 
decided  to  proceed  using  SunView,  at,  tempt,  ing  to  isolate  each 
Sunview  function  call  within  its  own  module  as  much  as 
possble.  Also,  using  an  available  graphics  package  ensured 
the  successful  i mp I emen tat i on  of  a  complete  tool. 


This  decision  limited  t.he  language  used  to  C .  This 
choice  did  not,  however,  detract  any  more  from  the 
portability  aspect  of  the  tool. 

Previous  Study  Considerations 

Since  data  dictionary  information  may  be  entered  into 
the  data  dictionary  database  from  sources  other  than  this 
tool  (currently  the  Data  Dictionary  Editor  is  the  only  other 
fool  with  this  capability),  there  were  existing  constraints 
on  the  field  lengths  for  the  data  dictionary  entries.  To 
meet  this  requirement,  the  field  lengths  specified  in  the 
Data  Dictionary  Editor  were  used  in  this  tool. 

From  IJrscheler’s  thesis  effort,  two  design  decisions 
were  carried  over.  First,  the  window  size  was  kept  the  same 
because  it  closely  represents  an  eight  by  eleven  inch  page 
size.  Second,  the  size  of  the  activity  boxes  was  kept 
constant.  Urscheler’s  testing  found  that  user-determined 
box  sizes  led  to  increased  software  and  data  structure 
complexity  (Urscheler,  1986,27). 

Human/Computer  Interface  Considerations 

The  importance  of  an  acceptable  human/computer 
interface  was  discussed  in  Chapter  Two  and  Chapter  Three. 

To  attain  this  objective,  the  design  decisions  surrounding 
t.he  screen  layout,  the  menus,  and  the  use  of  voice  for 
feedback  are  presented  in  the  following  paragraphs. 


Screen  Layout.  Figure  5  is  a  picture  of  the  actual 
screen  layout  used  by  the  tool.  It  was  decided  to  divide 
the  screen  into  five  distinct  areas  or  windows:  the  Input 
Window,  the  Message  Window,  the  Selection  Window,  the 
Diagram  Window,  and  the  Data  Dictionary  Window.  Each  of 
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Figure  5.  SA  Tool  Screen  Layout 
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these  windows,  except  the  Data  Dictionary  Window,  serves  a 
unique  purpose;  the  Data  Dictionary  Window  serves  two 
purposes.  The  following  briefly  discussed  the  role  of  each 
w i ndow . 

Diagram  text  is  typed  from  the  keyboard  and  is  echoed 
in  the  Input  Window,  which  is  located  at  the  top  of  the 
screen  layout.  For  each  input,  a  maximum  length  is  defined. 
Attempts  to  add  to  the  input  beyond  this  limit  are  not 
a l 1  owed .  Also,  errors  are  correctable  by  using  the  "DELETE" 
key  to  backspace  over  errors.  After  typing  the  input, 
striking  the  "RETURN"  key  puts  the  text  on  the  diagram. 

The  Message  Window,  located  directly  beneath  the 
Input  Window,  is  integral  to  the  user  interface  because  it 
is  the  primary  means  by  which  the  tool  keeps  the  user 
abreast  of  the  tool's  status.  Here  the  user  receives 
instructions  on  how  to  proceed  with  a  given  operation, 
feedback  on  the  results  of  a  particular  action,  and  help 
messages  on  how  to  resolve  a  problem  that  occurred.  The 
words  "Make  another  selection"  are  used  to  indicate  that  the 
current  operation  is  completed  and  the  program  is  ready  ho 
process  another  menu  selection.  The  menu  system  is 
discussed  in  more  detail  in  the  next  section  of  this 
chapt  er  . 

The  Selection  Window,  located  directly  below  the 
Message  Window,  is  where  the  user  selects  the  menu  that 
contains  t.he  next  desired  operation.  Five  ovals  are  laid 
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out  in  (ho  l  e  f  t- to- r  i  ght.  order  in  which  it  is  anticipated 
the  user  would  pick  the  menus.  For  example,  it  is 
anticipated  the  user  would  first  edit  the  diagram  by  adding 
and  deleting  lines,  boxes  and  labels.  Next,  the  user  would 
enter  the  applicable  data  dictionary  information  before 
getting  hardcopy  outputs  of  the  data  dictionaries,  the 
facing  page  text,  and  the  diagram.  Finally,  the  user  would 
save  the  diagram  for  possible  future  editing. 

The  Diagram  Window  is  located  underneath  the  Selection 
Window  and  is  where  the  SA  diagram  is  actually  "drawn."  In 
the  Diagram  Window  the  user  is  able  to  create,  delete,  and 
move  activity  boxes,  lines,  footnotes,  and  squiggle  lines. 

A  1  1  of  the  menu  selections  for  manipulating  these  and  ot.her 
graphical  entities  are  accessed  by  selecting  the  "EDIT 
DIAGRAM"  oval  in  the  Selection  Window. 

Finally,  the  Data  Dictionary  Window  is  a  dual-purpose 
window  located  below  the  Diagram  Window  where  data 
dictionary  information  that  cannot  be  derived  from  the 
graphical  inputs  is  entered.  The  user  enters  the  needed 
information  from  both  the  keyboard  and  the  mouse.  Using  the 
mouse,  the  user  quickly  moves  the  cursor  to  the  particular 
field  in  which  he  desires  to  enter  the  text.  The  Data 
Dictionary  Window  also  displays  the  current,  facing  page 
t.  ext. 

Menu  System.  Considering  the  nature  of  the  tasks  to  be 
accomplished,  a  menu  driven  system  was  chosen  because  it 
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satisfied  several  of  the  rules  for  a  good  user  interface 
Specifically,  a  menu  driven  system  offered  the  following 
advantages : 


1.  It  automatically  partitioned  the  input  process 
each  time  the  user  selects  another  operation. 

2.  It  minimized  the  memorization  required  by  the 
user . 

3.  It  gave  the  user  a  feeling  of  control  over 
the  tool  by  selecting  the  next  operation. 

4.  It  reduced  the  number  of  opportunities  for  the 
user  to  make  an  error  by  having  to  type  the 
select  ion . 

5.  It  permitted  a  uniform  selection  process. 


Making  a  selection  from  any  of  the  menus  is  a  uniform 


process.  With  the  mouse,  the  user  places  the  cursor  over 
the  text  of  the  desired  menu  selection.  When  the  selection 
is  changed  to  reverse-video,  the  selection  can  be  made  by 
('licking  the  left  button  on  the  mouse. 

Voice  Feedback.  This  tool  was  designed  to  accommodate 
a  DECTALK  ( DKCTALK  is  a  trademark  of  Digital  Equipment 
Corp.)  voice  synthesizer  running  version  2.0.  The  objective 
of  this  decision  is  to  enhance  the  human/computer  interface 
by  attempting  to  permit  the  user  to  concentrate  his 
attention  more  on  the  Diagram  Window  than  the  Message 
Window.  To  activate  this  option,  SAtooi  must,  be  executed 
with  a  -v  option  to  initialize  the  DECTALK.  A  software 
module  called  "put  message"  directs  messages  to  either  the 
DECTALK,  the  Message  Window,  or  both.  Due  to  the  time 
constraints,  this  capability  was  installed  in  the  tool,  but 
not  developed  or  evaluated. 

These  paragraphs  discussed  the  screen  layout,  menu 
setup,  and  voice  feedback  issues  in  the  design  of  the  tool. 
In  the  next  section,  the  data  structure  design  issues  are 
d i scussed . 

Data  Structures 

The  internal  data  structures  developed  for  this  project 
were  entirely  different  from  those  developed  in  the 
IJrseheler  prototype  (Urscheler,  1986:A-I).  Urscheler’s  data 
structures  were  designed  only  for  the  small  subset  of  the  HA 

I  -  it 


syntax  used  by  his  tool;  therefore,  new  data  structures  were 
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needed  to  implement,  graphical  entities  like  footnotes  and 
squiggle  lines.  In  addition,  this  researcher's  analysis  of 
the  prototype  concluded  that  the  low-level  approach  of 
treating  all  lines  (whether  they  made  up  an  activity  box  or 
lines  connecting  the  boxes)  and  all  text  (whether  it  labels 
the  diagram,  a  box,  or  a  line)  as  the  same  entity  resulted 
in  increased  software  complexity.  Based  on  this  analysis,  a 
higher  level,  object  oriented,  approach  was  taken. 

This  section  is  divided  into  two  parts.  First,  the 
primary  data  structures  and  the  information  they  store  are 
described.  Second,  the  data  dictionary  informat  ion  derived 
from  the  diagram  is  discussed. 

Primary  Data  Structures.  The  design  of  the  data 
structures  was  driven  largely  by  t.he  requirement  for  the 
tool  to  produce  one  separate  file  of  data  dictionary 
information  that  is  capable  of  being  stored  in  a  relational 
database.  This  requirement  led  to  the  following  design 
o b j ec  fives: 

1.  The  data  structures  must  maintain  both 

graphics  and  data  dictionary  information. 

2  .  The  dat.a  structures  must  separate  the  data 
dictionary  information  from  the  graphics 
information  as  much  as  possible. 

3.  The  dat.a  structures  must  maintain  enough 

informat  ion  to  allow  t.he  graphics  and  data 
dictionary  information  to  be  stored  in 
separate  fi 1 es  and  later  restored  from  those 
f i  I es  . 
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From  these  objectives,  five  primary  data  structures 
were  designed  to  ho  lei  all  the  graphics  and  data  dictionary 
information.  The  following  paragraphs  describe  each  of 
these  structures  and  how  the  data  dictionary  information 
relates  to  the  structure. 

The  box  structure  contains  the  information  needed  to 
locate  and  label  activity  boxes  as  well  as  store  data 
dictionary  information  not.  derived  f rom  the  diagram.  In 
addition,  each  box  structure  is  classified  as  such  by  a 
numeric  structure  type  field.  All  the  activity  boxes  on  the 
diagram  are  maintained  by  using  a  linked  list;  therefore,  a 
C  pointer  to  the  next  box  structure  was  also  defined. 

The  box  structure  uses  another  C  pointer  to  point  to  an 
activity  data  dictionary  structure.  This  structure  saves 
the  data  dictionary  information  input  by  the  user  and  is 
merged  with  the  diagram  information  to  complete  the  data 
dictionaries  for  activities.  Specifically,  the  user  must 
input  the  description  field,  alias  name  field,  alias  comment 
field,  version  changes  comment,  field,  and  related 
roqui  rement.  number  field. 

The  line  structure  contains  the  information  needed  to 
locate ,  label ,  and  draw  the  lines  as  well  as  store  the  data 
dictionary  information  not  derived  from  the  diagram.  Each 
1  i  ne  is  g  i  ven  a  numeric:  structure  type  that,  identifies  it. 
and  specifies  how  it  connect. s  to  other  lines.  In  addition 
to  the  label  identifying  the  data  it  represents,  a  line’  may 


have  ICOM  labels  attached  to  it,  specifying  the  line  as  a 
boundary  arrow,  and  a  label  that  is  placed  inside  a  TO-ALL 
or  FROM-ALL  circle  attached  to  one  end  of  the  line.  Also, 
two  numbers  are  defined  that  identify  the  graphical  entities 
drawn  on  each  end  of  the  line  ( ie.  arrowhead,  tunnel,  dot, 
turn  right,  or  branch  left,  etc.).  Finally,  the  lines  are 
stored  in  binary  trees  with  the  root  nodes  linked  to  other 
root  nodes  by  C  pointers.  Figure  7  shows  three  groups  of 
lines  and  the  corresponding  linked  list  structure  is  shown 
in  Figure  8.  It  can  be  seen  from  this  figure  that  this 
arrangement  is  advantageous  because  the  tree  arrangement 
maps  closely  to  how  the  line  segments  actually  connect  to 
one  another  and  because  C  supports  the  simple  recursive 
functions  used  for  traversing  binary  trees. 
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Structure 

The  1 ine  structure  uses  a  C  pointer  to  point  to  a  data 
dictionary  structure  representing  a  data  dictionary  for  a 
data  element.  This  structure  saves  the  data  dictionary 
information  input  by  the  user  and  is  merged  with  the  diagram 
information  to  complete  the  data  dictionaries  for  data 
elements.  Spec i f i cal ly ,  the  user  must  input  the  description 
field,  alias  name  field,  alias  comment  field,  related 
requirement,  number  field,  version  changes  comment  field, 
data  type  field,  minimum  value  field,  maximum  value  field, 
range  of  values  field,  values  field,  part  of  field,  and  the 
composition  field. 

The  squiggle  line  structure  contains  all  the 
information  needed  to  draw  a  squiggle  line.  A  squiggle  line 
is  strictly  a  graphical  entity,  needing  only  four  coordinate 
pairs  to  complete  its  specification.  Again,  a  squiggle  line 
classification  number  is  assigned  to  each  squiggle  on  the 
diagram.  The  squiggle  lines  for  a  particular  diagram  are 
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stored  in  a  singly  linked  list;  therefor*',  each  structure 
contains  a  (’  pointer  to  another  squiggle  line  structure'. 

The  header  structure  contains  all  the  informat  ion 
needed  to  draw,  locate,  and  classify  the  seven  header  fields 
of  an  SA  diagram.  Kxcept  for  the  number  field,  each  of  the 
fields  is  included  in  the  data  diet  ionaries  for  the  diagram. 
Since  each  diagram  only  has  one  header,  only  a  single  C. 
pointer  is  maintained  to  save  t.h  i  s  information. 

The  last  primary  storage  structure,  the  footnote 
structure',  keeps  all  t.h*'  information  needed  to  draw,  locate, 
and  classify  a  matching  pair  of  footnote  labels.  I.ike  the 
squiggle  line,  this  information  is  strictly  graphical.  The 
footnote  structures  for  a  diagram  are  stored  in  a  singly 
linked  list;  therefore,  a  C  pointer  to  another  footnote 
structure  is  defined. 

Data  Dictionary  Information  Derived  from  the  Graphics 
Information.  So  far  in  this  section,  the  graphical 
informal  ion  stored  in  the  various  structures  and  the  data 
dictionary  information  not  contained  in  the  graphics 
information  has  been  identified  .  The  purpose  of  the 
following  paragraphs  is  to  identify  the  data  dictionary 
information  that  is  derived  from  the  graphics  informat  ion. 

Tn  an  activity  data  dictionary,  the  header  structure 
directly  provides  five  data  dictionary  inputs  and  part  of  a 
sixth.  The  PROJKCT,  DATK ,  and  AUTHOR  fields  are  exact 
matches  with  the  fields  of  t.he  same  title  in  the'  data 
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dictionary.  The  NUMBER  fit' Id  of  the  data  dictionary  is  the 
result  of  appending  t.he  number  of  the  activity  box  to  the 
NODE  field  of  the  diagram.  The  PARENT  ACTIVITY  and  VERSION 
fields  of  the  data  dictionary  are  synonymous  with  the  TITLE 
and  REV  fields  of  the  diagram,  respect,  i  ve  1  y  . 

The  INPUTS,  OUTPUTS,  CONTROLS,  and  MECHANISM  fields  of 
t.he  data  diet  ionary  art'  derived  by  matching  the  starting  and 
ending  points  of  a  line  segment,  w  i  t.h  the  boundary  of  the 
activity  boxes.  When  one  of  the  line’s  start  or  end  points 
matches  a  box  boundary,  t.he  side  of  the  activity  box 
determines  the  appropriate  field  and  then  tree  traversal 
algorithms  can  find  the  closest  label  t.o  the  box. 

In  a  data  dictionary  for  a  data  element,  the'  header 
structure  directly  provides  four  data  dictionary  inputs. 

The  PROJECT,  DATE,  and  AUTHOR  fields  are  exact  matches  of 
fields  with  the  same  title  in  the  data  dictionary.  Also, 
the  VERSION  field  of  the  data  dictionary  is  the  same  as  the 
REV  field  of  the  diagram. 

The  SOURCES  and  DESTINATIONS  field  of  the  data 
dictionary  cannot  consistently  be  resolved  by  the  tool.  It 
is  possible  in  an  SA  diagram  to  have  a  valid  data  entity 
that  has  no  sources  or  destinations  due  to  the  pipeline' 
feature  of  the  language.  Current,  ly,  the  data  dictionary  is 
unable  t.o  handle  this  situation  with  the  precision  needed 
for  implementation  with  the  tool;  therefore,  the  tool  I  eaves 
these  spaces  blank. 
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This  section  discussed  the  design  of  t.he  data 
structures  and  the  information  they  contain.  This 
information  is  used  to  generate  output  products,  and  the 
information  is  stored  in  files.  These  files  of  information 
are  discussed  in  the  next  section. 

Data  F i les 

Like  the  data  structures  used  by  the  tool ,  the  data 
files  each  have  their  own  format  that  is  different  from 
Urscheler’s  prototype .  The  tool  is  capable  of  creating  five 
different  data  files,  two  that  save  the  raw  data  (graphics 
and  data  dictionary  information)  and  three  that  save  the 
output  products  from  the  tool.  The  following  paragraphs 
briefly  describe  the  files  and  their  formats. 

The  graphics  information  from  the  diagram  is  maintained 
in  an  ASCII  file  labeled  as  < f i iename > . gph .  In  the  file, 
squiggle  line,  footnote,  box,  and  line  information  is  saved 
in  a  precisely  formatted  manner.  If  a  field  has  been  left 
blank  by  the  user,  a  "$$NIJ1,L$$"  string  is  placed  in  the  file 
as  a  place  holder.  Appendix  0  contains  an  exact  definition 
of  how  this  file  is  stored . 

The  data  dictionary  information  from  the  diagram  is 
ma i n  t  a l ned  i n  an  ASC II  file  1 abe 1 ed  as  <  f i  l  ename  >  . d  bs .  The 
data  diet  ionaries  for  each  act.ivit.y  and  only  the  data 
dictionary  data  elements  defined  by  the  user  are  saved  in 
this  f  l  1  e  .  The  design  of  this  file  f  o  rmat.  is  the  result  of 
another  thesis  in  progress  at.  t.he  time  of  this  writing 


( Conna  i  1  y  ,  1987:).  This  f  orraat.  is  a  1  so  def  i  ned  i  n  Append  i  x 

C  . 

The  facing  page  text  for  the  diagram  is  saved  (at  the 
option  of  the  user)  in  an  ASCII  file  iabeLed  as 
< f i I ename > . f pt .  The  facing  page  text  is  a  copy  of  the 

description  fields  of  the  data  dictionaries  for  each 
activity  box.  The  format  in  which  it  is  saved  is  specified 
in  Appendix  A. 

The  user  also  has  the  option  of  saving  in  a  file  a 
formatted  copy  of  all  or  selected  data  dictionaries.  This 
file  is  an  ASCI  I  file  that  is  1  a be  led  as  <  f i 1 ename  > . dd .  The 
format  for  this  type  of  file  is  also  specified  in  Appendix 
A  . 

The  user  has  the  option  of  saving  a  copy  of  the  diagram 
generated.  This  file  contains  a  SDN  raster  image  of  the 
diagram  that  is  labeled  as  < f i 1 ename >. dmp .  SunView  raster 
functions  are  used  to  read  the  diagram  image  from  the  screen 
and  save  it  in  the  SUN’s  raster  file  format.  The  user  may 
obtain  hardcopy  by  using  the  UNIX  " 1 pr  -v"  command. 

Cod i ng  Approach 

Having  completed  the  design  specification,  defined  the 
dat.a  structures,  and  defined  the  file  formats,  the  next  step 
was  the  act.ual  coding  of  the  modules.  As  previously 
merit  ioned,  the  programming  language  used  to  implement,  this 
t  in;  I  was  C.  This  sect,  ion  describes  the  coding  approach. 


A  top  down  approach  (Pressman,  1982:232)  was  taken  in 
developing  the  modules.  The  process  started  by  developing 
the  main  control  module:  that  called  the  appropriate1 
functions  associated  with  each  menu  selection.  With  the 
control  structure  and  numerous  module  "stubs”  in  place:,  the 
module  stubs  were  replaced  with  the  real  code  and  each 
stub's  lower  level  modules  until  the  project  was  complete. 

Internal  documentation  of  the  code  followed  t.hat. 
prescribed  in  the  AFIT/ENG  Software  Development 
Documentation  Guidelines  and  Standards.  Each  file  began 
with  the  standard  file  header  (Hartruro,  1986:38)  and  each 
module  began  with  the  standard  module  header  (Hart, rum, 
1986:10).  In  addition,  C  language  comments  were  provided  in 
the  code?  to  amplify  and  clarify  sections  of  the  code. 

Testing  Approach 

Testing  was  accomplished  in  conjunction  with  the  coding 
phase  in  this  project.  A  slightly  "impure”  integration  test 
method  was  applied  (Pressman,  1982:298-9).  The  procedure 
was  impure  because  neither  the  depth-first  or  bread th - f i rs t 
incorporation  approach  to  integrating  new  software  into  the 
existing  software  was  consistently  applied  due  t.o  the  t  ime 
constraints  of  the  project.  Typically,  about  ten  modules 
were  written  and  added  t.o  the  software  before  applying  the 
t.  e  s  t.  s  . 

Obviously,  an  exhaustive  test  was  impossible  for  a 
project,  of  this  magnitude;  however,  the  tests  conducted 
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attempted  to  fissure  that  all  module  paths  were  exercised  at 
least  once,  that  all  conditional  statements  were  verified, 
that  each  module  provided  the  needed  function,  and  that 
errors  were  properly  handled.  To  assist  future 
maintenance  actions  on  the  code,  debugging  "printf" 
statements  identifying  its  position  in  the  code  were  used  to 
alert  the  user  when  an  unanticipated  condition  did  occur. 

Summary 

This  chapter  discussed  the  design  decisions  based  on 
the  requirements  and  objectives  of  the  thesis.  Five 
reasons  why  the  SUN  workstations  met  the  hardware 
requirements  were  stated.  Second,  portability  of  the  tool, 
reusability  of  the  Urscheler  code,  and  suitability  of  the 
SunView  environment  were  issues  covered  by  the  software 
considerations.  Considerations  from  previous  studies  found 
data  dictionary  constraints  that  were  maintained  in  this 
tool  and  found  design  decisions  that  were  carried  over  from 
past  works.  Next,  the  screen  layout,  menu  system,  and  use 
of  voice  were  identified  as  the  key  human/computer  interface 
topics  that  concerned  this  tool.  Also,  decisions  involved 
in  the  design  of  the  data  structures  and  data  files  were 
identified.  Finally,  coding  and  testing  approaches  were 
explained  in  the  last,  two  parts  of  the  section.  Given  this 
information,  the  next,  chapter  discusses  t.he  tool’s  operation 
and  the  results  of  the  tool's  evaluation. 
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V.  SA  TOOL  OPERATION  AND  EVALUATION 

The  issues  and  decisions  surrounding  the  design  of  the 
tool  were  discussed  in  the  previous  chapter.  The  purpose  of 
this  chapter  is  to  provide  a  broad  overview  of  how  the  tool 
operates  and  to  report  the  results  of  the  tool’s  evaluation 
by  a  group  of  AEIT  students. 

This  chapter  will  first  discuss  the  tool  and  its 
function  and  then  report  the  evaluation  results.  The  first 
section  presents  the  tool’s  function  in  six  parts: 
initialization,  graphics  functions,  data  dictionary 
functions,  facing  page  text  functions,  input/output 
functions,  and  miscellaneous  functions.  The  user  is 
referred  to  the  User’s  Reference  Manual  (Appendix  J)  for  a 
complete  discussion  of  all  the  available  functions.  The 
first  part  discusses  the  initialization  of  the  tool. 

Operat.  ion 

Initialization.  To  start  the  tool  running,  the  user 
must  first  invoke  the  Suntool  environment.  This  is 
accomplished  by  entering  the  command  "suntools"  at  the  UNIX 
prompt.  Once  a  C-shell  window  has  been  opened,  the  user  is 
ready  to  run  the  tool. 

Th  e  command  to  start  the  tool  is  "SAtool."  The  tool 
was  designed  to  accept  a  -v  option  to  enable  the  use  of  a 
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DEOTAl.K  voice  synthesizer  to  provide  audio  feedback  for 
the  user;  however,  this  feature  was  not  implemented  due  to 
the  time  constraints  involved  in  the  project.  The  user  is 
now  ready  to  begin  using  the  tool  and  may  select  one  of  the 
oval  buttons  in  the  Selection  Window  for  a  menu  of  choices. 

Graphics  Functions.  The  graphics  functions,  located  on 
menus  under  the  "EDIT  DIAGRAM"  oval  ,  contain  al  1  t.he 
functions  needed  to  draw  and  label  an  SA  diagram.  The 
functions  make  it  possible  to  add  a  new  or  edit  an  existing 
graphical  entity  (activity  box,  ICOM  line,  squiggle  line, 
diagram  label,  or  footnote  marker). 

Five  operations  are  permitted  on  activity  boxes. 

Adding  an  activity  box  involves  setting  the  location  of  the 
box  as  well  as  entering  the  box  name  and  box  number.  To 
edit  one  of  the  box  attributes,  the  user  identifies  which 
box  by  placing  the  cursor  inside  the  box  and  clicking  a 
mouse  button.  Each  of  the  operations  involved  in  adding  a 
box,  setting  the  location  and  entering  the  name  and  number, 
may  be  changed  by  picking  the  appropriate  menu  selection. 
Finally,  an  existing  activity  box  may  be  deleted. 

Six  operations  are  permitted  on  lines.  Adding  a 
line  involves  selecting  the  two  endpoints  using  the  mouse 
and  selecting  the  begin  and  end  attributes  from  their 
respective  menus.  If  the  end  attribute  is  a  Branch  or  Turn, 
the  tool  automatical  ly  positions  the  cursor  at,  the  end  of 
t.he  Branch  or  Turn  to  cont,  i  nue  drawing  the  line.  To  add  or 
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change  a  line  label,  the  user  selects  the  menu  function, 

"  Ed  i  t.  Line  Label,"  and  moves  the  cursor  to  a  point,  on  the 
line  and  clicks  the  mouse  to  select  the  line.  The  text,  is 
then  entered  from  the  keyboard.  A  TO-ALL,  FROM-ALL,  or  I  COM 
label,  specified  when  a  line  is  added,  may  be  changed  by 
selecting  "Edit  TO/ FROM  Label"  or  "Edit  1  COM  Label." 
finally,  the  line  may  be  deleted  entirely  or  redrawn  with 
the  "Redraw/Delete  Line"  selection.  The  choice  of  these  two 
operations  is  made  by  clicking  a  mouse  button.  The  Redraw 
function  deletes  a  line  and  any  connected  to  it  and  starts 
the  user  re-drawing  the  line  with  the  original  beginning 
attributes. 

Fifteen  operations  are  permitted  on  the  seven 
diagram  header  labels.  Each  diagram  header  label  may  be 
first  added,  or  later  edited,  for  a  total  of  fourteen.  The 
fifteenth  operation,  useful  at  the  start  of  a  new  diagram, 
allows  the  addition  of  all  seven  header  fields  without 
selecting  each  operation  individually. 

Four  operations  are  permitted  on  footnotes. 

Since  the  footnotes  are  created  and  maintained  in  pairs  of 
identical  boxes,  creating  a  footnote  box  pair  involves 
first  specifying  the  number  label  for  both  boxes,  then 
moving  each  box  to  its  desired  location.  Changing  the 
footnote  number  will  change  the  number  in  both  boxes  while 
changing  a  footnote  location  moves  only  one  of  the  pair  at  a 
time.  To  delete  a  footnote  box  pair,  the  user  places  the 


cursor  inside  one  of  the  footnote  boxes  and  ('licks  a  mouse 
button;  both  boxes  are  thi  ■'  deleted  from  the  diagram. 

Two  operations  are  permit. ted  on  squiggle  lines, 
creating  and  deleting.  To  create  a  squiggle  line,  the  user 
is  allowed  to  draw  three,  "free-hand”  line  segments.  To 
delete  a  squiggle  line,  the  appropriate  squiggle  line  is 
selected  by  placing  the  cursor  on  a  point  on  one  of  the  line 
segments  and  clicks  a  mouse  button.  The  squiggle  line  is 
then  removed  from  the  diagram. 

Having  considered  the  functions  needed  to  create  and 
od  i  t.  the  SA  diagram  entities,  the  next  paragraphs  discuss 
the  functions  needed  to  complete  the?  data  dictionary 
i n  format  ion. 

Data  Dictionary  Functions.  The  data  dictionary 
functions,  located  on  menus  under  the  "EDIT  DD"  oval, 
contain  all  the  functions  needed  to  enter  and  edit  any  data 
dictionary  information  for  the  diagram.  The  information  is 
entered  via  the  Data  Dictionary  Window. 

There  are  five  operations  available  for  managing  the 
data  dictionary  information.  "ADD  DD”  is  used  to  create 
storage  for  data  dictionary  information  for  a  line.  The 
user  selects  the  line  by  moving  the  cursor  on  the  line  and 
clicking  a  mouse  button.  The  data  dictionary  template  is 
placed  in  the  Dat.  Dictionary  Window  with  the  number  in 
parentheses  before  t.he  field  name  specifying  the  width  01 
t he  field.  While  entering  the  information,  the  "ADD  MORE 
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ALIASES"  selec  t,  ion  adds  another  alias  block  to  the  existing 
template.  Reviewing  or  further  editing  an  existing  data 
dict  ionary  is  the  purpose  of  t.he  "EDIT  1)D"  function. 

(Recall  that  dat.a  dictionaries  for  activity  boxes  are 
automatically  generated.)  Selecting  "DD- !•’  1  N  I SHK1)"  causes 
the  information  in  the  Data  Dictionary  Window  t.o  bo 
collected  and  stored  in  the  data  dictionary  data  structures. 
Final ly,  "SAVE  DD  IN  FILE"  permits  the  user  to  select  one  or 
more  dat.a  dictionaries  or  all  data  dictionaries  for  saving 
in  an  ASCII  file  in  the  format  specified  in  Appendix  A. 

Facing  Page  Text  Functions.  Located  under  the  "FPT 
FIJNCT I ONS "  oval  are  two  facing  page  text  functions .  Both 
operations  build  the  facing  page  text  according  to  the 
format  in  Appendix  A  from  the  descriptions  entered  in  the 
data  dictionary.  The  first  function  displays  this 
information  in  the  Data  Dictionary  Window  while  the  second 
function  puts  the  information  in  an  ASCII  file. 

Input/Output  Functions.  The  input  and  output  functions 
are  located  under  the  "RECALL  DIAGRAM"  and  "SAVE  DIAGRAM” 
ovals,  respectively.  A  previously  saved  diagram  may  be  read 
in  with  the  "RECALL  DIAGRAM"  function  by  specifying  the 
filename  (without,  a  dot  (.)  extension).  The  program  checks 
the  working  directory  for  files  named  with  the  given  file 
name  plus  ”.dbs”  and  ”.gph"  extensions  and  loads  their 


information  into  the  data  structures. 
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The  diagram  current  iy  stored  in  the  tool  ’s  data 
structures  may  be  saved  in  a  similar  manner,  wit.h  the;  tool 
adding  the  dot  extensions  to  the  file  name.  The  user 
selects  either  "Save  for  DB"  to  create  a  ".dbs"  file  for 
saving  in  a  relational  database  or  "Save  Local"  to  create  a 
file  wit.h  a  ".dbs"  file  that  is  not  compatible  with  the 
database  tool,  yet  remains  compatible  with  this  tool. 

Miscellaneous  Functions.  The  miscellaneous  functions, 
found  under  the  "MTSC  FUNCTIONS"  oval,  contain  operations  to 
save  a  file  t.hat  generates  a  hardcopy  of  the  diagram, 
to  manipulate  the  working  directory,  to  erase  the  current 
diagram  and  data  dictionary,  to  redisplay  the  Diagram 
Window,  and  to  quit  the  tool.  "Make  Diagram  (Normal)"  and 
"Make  Diagram  (Sideways)"  may  be  selected  depending  on  the 
desired  orientation  of  the  SA  diagram  on  the  page.  The  user 
specifies  a  file  name  and  the  tool  adds  a  ".dd"  extension  to 
the  file  t.hat  can  be  printed  on  SUN  laser  printer.  The 
current  working  directory  is  displayed  in  the  Message  Window 
by  selecting  "Display  Directory"  or  can  be  changed  by 
selecting  the  "Change  Directory"  function.  "Start  New 
Diagram"  erases  the  Diagram  Window  and  empties  the  data 
structures  of  the  information  being  stored.  The  "Redisplay 
Diagram"  and  "QUIT"  functions  are  self  explanatory. 

Given  this  broad  overview  of  the  tool  and  its 
operation,  the  next  section  discusses  the  results  of  an 
evaluation  of  t.he  tool  . 
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Evaluation  Results 

Two  graduate  software  engineering  classes  at  AF'IT  used 
the  tool  in  conjunction  with  a  homework  problem  and 
evaluated  their  experiences  with  the  tool.  In  this  section, 
the  evaluation  methodology  is  described  followed  by  the 
conditions  surrounding  the  evaluation.  Final iy,  the  results 
of  the  evaluation  are  presented. 

Evaluation  Methodology.  The  student’s  reactions  to  t.he 
tool  were  gathered  using  a  quantitative  questionnaire 
developed  at  AFIT  (Mall ary,  1985:  81-5;  Foley:1986).  For 
the  purposes  of  this  evaluation,  the  use  of  this  method  was 
assumed  valid.  The  questionnaire  consisted  of  12  questions 
regarding  different  aspects  of  the  tool.  Figure  9  is  an 
example  of  one  of  these  questions.  Figure  10  is  a  list  of 
the  12  questions.  Question  12  gathers  an  overall  rating  of 
satisfaction  that  was  compared  to  the  average  of  the  other 
1 1  quest  i  ons  . 

Each  of  the  first  11  questions  was  rated  on  a  scale 
from  -3  to  3  on  four  adjective-pairs.  For  each  user  i  and 
question  j,  these  four  scores  were  averaged  to  give  a 
reaction  score  Rij.  Each  question  also  had  an  overall 
satisfaction  score  for  correlation  with  the  average  of  the 
adjective-pair  score  (unused  in  this  evaluation).  Finally, 
to  weight  the  adjective-pair  score  {  W  i  ,j  )  ,  each  question 
allowed  the  user  to  rate  the  importance  of  the  particular 


factor  to  him  on  a  scale  of  0  t.o  1. 


From  this  information,  a  normalized  satisfaction  score 


NS  for  each  user  was  computed  as 


-  1  / ( 3  *  N i  )  V]  Rij  *  Wi j 


where  Ni  is  the  number  of  questions  whose  reaction  score  Rij 
was  not  zero.  The  normalized  satisfaction  score  indicates 
the  degree  of  user  satisfaction  according  to  Table  I. 


1 .  System  Feedback:  The  extent  to  which  the 
system  kept  you  informed  about,  what  was  going  on 
in  the  program. 
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_!  good 


J  I  satisfactory 


J  important 


Comments : 


Figure  9.  Example  Evaluation  Question  Format 

Source:  (Mallary,  1985:111) 


Evaluation  Conditions.  Thirty-three  students  were 
assigned  to  make  one  diagram  using  the  tool  and  complete  the 
evaluation  based  on  that  experience.  Each  student  was  given 
a  guide  that  explained  the  workstation’s  login  and  logout 
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TAB I  K  1 

Ba  i  1  »'y  and  Pearson  Ratings 


NORMAL  I  XKB  STORK 


TRANSLATION 


t  1  .  00 

+  0 .67 
+  0 . 3  3 
to  .  0 
-0 . 33 
-0 .67 
-1.00 


Maximally  satisfied 
Quite  satisfied 
Slightly  satisfied 
Neutra I 

Slightly  dissatisfied 
Quite  dissatisfied 
Maximally  dissatisfied 


Source:  (Mallary,  1985) 


procedures,  error  recovery  procedures,  menu  selection 
procedures,  and  the  components  of  the  screen  layout. 
Information  regarding  the  exact  function  provided  by  each 
menu  selection  was  not  available  to  give  to  the  first  class 
of  students;  therefore,  it  was  not  provided  to  the  second 
class  to  maintain  consistency  across  the  two  classes. 

Evaluation  Results.  The  average  of  the  normalized 
scores  for  the  first  11  questions  of  the  evaluations  was 
0.295  or  about  "Slightly  Satisfied"  according  to  the 
translation  of  Table  I.  The  scores  ranged  from  -0.182  to 
.682  wit.h  a  standard  deviation  from  the  mean  of  0.294.  Thi 
compares  closely  with  an  average  0.333  "overall 
sat  infant  ion”  rat.ing  given  on  question  12.  On  the  average, 
the  oval  ul  at.ors  used  the  tool  about  138  minutes.  Table'  1  I 


shows  how  the  evaluation  broke  down  by  quest,  ion. 


System  Feedback  or  content  ot  the  Inrormat  ion 
Displayed.  The  extent  to  which  the  system 
kept,  you  informed  about  what,  was  go  i  nit  on  in  t  he 
prog  r  am . 

Communication.  The  methods  used  Co 
communicate  with  the  tool  . 

Frror  Prevention.  Your  perception  of  how  wo! ! 
the  system  prevented  user  induced  errors'. 

Frror  Recovery.  The  extent  and  ease  wi ! h 
which  t  h  e  system  allowed  you  to  recover  from 
use  r  induced  errors. 

documental  ion.  Yeur  overall  perrept  ion  as  to 
the  im’  I'll  I  ness  of  the  doc  u(D<  ri  I  a  t  i  or,  . 

F\ pee  tat  i.ms;.  Your  percept  ion  as;  to  the 
ser\  ices  pro\  tiled  by  t  he  system  based  on  your 
expii  t  at.  i  on s  . 

Confidence  in  the  System.  Your  feelings  of 
assurance  or  certainty  about  the  serv  ices 
provided  by  the  system. 

8 .  Ease  of  Learning.  Ease  with  which  you  were; 
able  to  learn  how  to  use  the  system  to 
generate  1DEF0  definitions. 

9.  Display  oj"  Information.  The  manner  in  which 
both  program  control  and  1DEFU  informat,  ion  was 
displayed  on  the  screen. 

10.  Feeling  of  Control.  Your  ability  to  direct,  or 
control  t.he  activities  performed  by  SAt.ool. 

1  1  .  Relevancy  or  System  Usefulness.  Your 

perception  of  how  useful  the  system  is  as  an 
aid  to  a  software  developer. 

\2.  Overall  Evaluation  of  the  System.  Your 
overall  satisfaction  with  the  system. 


Figure  10.  Evaluation  Questions 


TABLE  II 


Average  Normalized  Score  by  Question 


QUESTION 

AVERAGE  NORMALIZED 

1 

0.483 

2 

0 . 399 

3 

0 . 060 

4 

-0 . 056 

5 

-0.055 

6 

0.3  18 

7 

0 .406 

8 

0 .406 

9 

0.453 

10 

0. 346 

l  1 

0.475 

12 

0.333 

The  lack  of  adequate  documentation  of  the  tool  for  the 
evaluation  probably  contributed  heavily  to  the  lower  scores 
received  on  questions  3,  4,  and  5.  One  user  commented,  "I 
would  rather  read  and  see  example  displays,  as  opposed  to 
the  trial  and  error  method  (of  learning  the  tool)."  With 
regard  to  question  5,  the  users  frequently  commented  they 
could  find  no  documentation,  and  four  users  failed  to  even 
rate  the  question.  Regarding  question  4,  users  described 
mistakes  they  made  in  drawing  the  diagram,  noting  they  were 
unable  to  undo  t.he  error.  In  every  case  there  was  a  menu 
selection  avai lable  to  undo  the  error,  but  the  person  was 
apparently  unaware  of  t.he  selection’s  existence.  llv  the 
same  reasoning  regarding  quest,  ion  3,  the  users  probably  made 


more  errors  experimenting  with  the  menu  selections  trying  to 


determine  their  funct  ionality,  lf?avin^  an  impression  of 
poorer  t  ban  expected  error  p  re  ven  t.  1  on  capability. 

The  users  offered  suggest  ions  for  improving  t.he  tool  . 
For  instance,  one  suggested  that  a  help  selection  be  added 
to  each  of  the  menus.  This  would  be  a  useful  and 
straightforward  addition  to  t.he  tool.  Also,  it  was 
suggested  that,  a  universal  undo  command  for  each  menu 
selection  be  made  available.  This  would  also  be  useful,  but 
much  less  straightforward  to  implement.. 

Summary 

This  chapter  discussed  the  operation  of  the  tool  anti  an 
evaluation  of  the  tool.  It.  gave  procedures  for  invoking  the 
Sun  tool  environment,  and  t.he  SAtool.  Each  operation 
permit  ted  on  t.he  five  major  graphical  entities  (activity 
boxes,  [COM  lines,  squiggle  lines,  diagram  labels,  and 
footnote  markers)  was  identified  and  described.  Next.,  the 
data  dictionary  capabilities  of  the  tool  were  described 
followed  by  t.he  facing  page  text,  functions.  Following  this 
description  was  a  discussion  of  the  input/output  functions. 
Finally,  some  miscellaneous  functions  provided  by  the  tool 
were  described. 

An  evaluation  of  the  tool  was  performed  using  a 
quantitative  questionnaire  and  statistical  analysis  of  the 
results.  The  method  of  computing  the  normal i zed 
satisfaction  score  was  detai  let!  as  wo  I  1  as  the  cond  i  t  ions 
under  which  the  experiment,  was  conducted.  I'he  results  found 
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that  users  were  ''.slightly  satisfied"  wit.h  the  performance  of 
t  he  t  on  1  . 

The  following  chapter  presents  t,he  researcher’s 
conclusions  from  conducting  this  thesis  and  recommends 
several  future  projects  as  a  result  of  t.his  effort. 


V  I  . 


CONCLUSIONS  AND  KKCOMMKNDAT I ONS 


Cone  1  us  Lons 

The  purpose  of  this  thesis  was  to  specify  and  design  a 
tool  that  allows  a  user  to  interactively  create  and  edit 
structured  analysis  diagrams.  In  addition,  partial  data 
dictionary  information  is  automatically  generated  from 
graphics  information  by  the  tool  and  is  supplemented  by 
inputs  from  t.he  user. 

Each  of  the  three  phases  of  this  effort  was 
accomplished  successfully.  During  the  first  phase,  the 
Urseheler  implementation  was  analyzed  and  the  reusable  parts 
of  his  software  were  identified.  Also,  a  graphical  SA 
language  was  derived  from  several  sources  and  a  subset 
identified  for  implementation  in  this  tool.  During  the 
second  phase,  the  structured  analysis  and  data  dictionary 
methodologies  were  combined  and  the  tool  was  built  and 
successfully  tested.  During  the  third  phase,  the  usefulness 
of  the  tool  was  evaluated  by  polling  people  who  used  the? 
tool  for  a  classroom  software  engineering  project. 

The  evaluation  found  the  users  were  "slightly 
satisfied"  with  the  performance  of  t.he  tool.  Three 
questions  rating  t.he  documentation,  error  prevention,  and 
error  recovery  capabilities  were  given  significantly  lower 
ratings  because  no  documentation  of  each  function  provided 
the  fool  was  avai lable  at  the  time  of  the  experiment. 


Although  the  objectives  of  this  thesis  were 
accomplished,  there  are  several  aspects  of  the  tool  that 
could  be  enhanced  to  make  it  a  better  product.  These 
aspects  are  enumerated  in  the  next  section. 

Reeommendat ions 

The  recommendations  are  divided  into  two  categories: 
small  scale  projects  and  large  scale  projects.  Presented 
first,  are  the  small  scale  projects. 

Small  Scale  Projects.  The  following  are  recommended 
small  scale  projects  for  improving  the  tool: 

1.  Integrate  the  use  of  voice.  This  project 
should  go  back  and  analyze  the  ’’put  message!)" 
functions  that  provide  the  user  with  feedback 
in  the  tool’s  Message  Window.  This  function 
was  designed  to  send  messages  either  to  the 
Message  Window  or  a  Dectalk  voice  synthesizer 
or  both.  Currently,  all  messages  are  routed 
to  the  Message  Window.  Developing  this 
capability  could  enhance  the  human/computer 
interface . 

2.  Improve  the  method  for  making  hardcopies  of 
the  diagram.  The  current,  method  reproduces  a 
pixel  by  pixel  image  of  the  Diagram  Window 
into  a  SUN  rasterfile.  A  method  should  be 
considered  that  would  command  the  printer  to 
draw  lines  and  text  rather  than  generating 
pixel  by  pixel  images. 

3.  Improve  the  method  by  which  the  user  inputs 
data  dictionary  information.  The  current 
method  uses  a  generic  editor  that  is  unable  t.o 
prevent  the  user  from  entering  information 
past  the  end  of  the  different  length  fields. 

If  the  information  exceeds  the  field  boundary, 
the  information  is  truncated  when  it  is  saved. 

A  method  should  be  investigated  that  will  not. 
al  low  the  user  t.o  enter  information  beyond  the 
end  of  the  field. 
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1  .  (Tampa  t  i  b  i  1  i  t.  y  lest  t,h  i  s  too  1  with  Ko  ley’s  too  1 
via  the  relational  database.  The  data 
dictionary  information  for  this  tool  was 
designed  to  match  that  of  the  Foley  editor. 
Testing  should  be  conducted  to  ascertain  the 
compatibility  of  the  two  tools. 

f>  .  Provide  on-line  help.  Currently,  help  from 
the  tool  is  provided  via  the  Message  Window. 

Due  to  the  size  of  the  window,  help  messages 
tend  to  be  cryptic.  Therefore,  a  method  of 
providing  more  in-dept.h  explanations  of 
commands  from  the  tool  should  be  considered. 
Adding  one  "help"  selection  to  each  menu  has 
been  suggested. 

Large  Seale  Projects.  The  following  are  recommended 
large  scale  projects  for  improving  the  tool : 

1  .  Convert,  the  tool  from  SunView  to  a  standard 
graphical  package  1 i ke  GKS .  Converting  to  a 
graphics  standard  would  increase  the 
possibility  of  porting  the  tool  other 
workstat ions . 

2.  Make  the  tool  capable  of  handling  an  entire 

project.  This  would  require  adding  more  data 
structures  to  maintain  the  graphical  and  data 
dictionary  information  for  all  the  diagrams  in 
a  given  project.  This  enhancement  would 
allow  more  consistency  checking  algorithms  for 
the  data  and  allow  the  tool  to  generate  more 
complete  dat.a  dictionaries  for  data  elements. 
Also,  a  method  to  walk  through  the  diagram 
hierarchy  would  need  to  be  implemented. 

Examining  current  commercial  tools  and  their 
"explode"  capability,  the  ability  to  see  an 
activity  box’s  decomposition  by  exploding  the 
box  for  a  "closer"  look  inside,  might  be 
helpful . 

■'!  .  Remove!  the  necessity  of  maintaining  graphical 
information.  This  would  require  an  analysis 
of  the  dat.a  dictionary  format  to  ensure  it  is 
capable  of  holding  all  the  informat,  ion 
contained  in  a  graphical  picture.  Once  this 
is  proven,  it,  should  be  possible  to 
automat  ical ly  draw  the  diagram  from  the 
informat. ion  contained  in  the  data  dictionary. 
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Add  color  to  enhance  the  human/eomput.er 
interface.  Colors  might  be  used  to  reflect, 
the  presence  of  data  dictionary  information 
for  a  1 i ne  or  to  reflect  the  presence  of  poor 
coupling  and  cohesion  characteristics  among 
t ho  act  ivity  boxes  to  suggest  just  of  few  of 
the  possibi 1 ities.  Here,  a  trade-off  with 
portability  should  lie  carefully  considered. 

Redo  the  entire  project  in  Ada.  This  project 
would  be  contingent  upon  the  upgrade  of 
SunView  to  support  Ada.  This  project  would 
make  the  tool  better  suited  for  use  by  other 
agencies  in  the  IJ .  S .  government.,  given  its 
requirement  for  using  Ada  for  all  new 
software  developments. 
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Appendix  A: 


A  KIT  STRUOTURKI)  ANALYSIS  SYNTAX 


The  pur-post?  of  this  appendix  is  to  precisely  define  the 
formats  of  the  documents  generated  by  t he  structured 
analysis  tool.  The  AFIT  syntax  for  structured  analysis 
diagrams  is  derived  from  SADT  and  IDKKq  graphic  syntax. 

Also,  the  format  for  the  data  diet. ionary  entries,  and  the 
format  for  facing  page  text  is  specified. 

SADT  and  IDKKq 

A  tabulation  of  the  SADT  language’s  syntax  and  concepts 
was  presented  in  a  paper  by  Douglas  Ross  in  1977  (Ross, 

1977).  Kigure  11  is  the  figure  presented  in  that  paper. 

The  subset  of  the  SADT  syntax  used  by  IDKKq  was  defined 
in  the  "User's  Reference  Manual,"  published  by  the  Materials 
Laboratory  at  Wr  i  ght. -Patterson  AKB ,  Ohio  (IDKKq  Manual, 

1981).  Some  of  the  language  used  in  example  diagrams  was 
not  described  in  the  text.  Therefore,  Figure  \2 
was  generated  to  summarize  the  IDKKq  synt.ax  in  a  table  based 
on  the  example  diagrams  and  text  in  IDKKq  user’s  manual  . 
Additionally,  the  column  called  "term"  was  the  name  by  which 
each  notation  was  referred.  Some  entries  in  the  Ross 
art  i  c  1  e  table  are  methods  and  not.  graph  i  ca  1  entities; 
therefore,  they  cannot,  be  implemented  in  a  (’AD  t.oo  I  .  An 
example  of  this  is  Line  96  in  Figure  li. 
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IDEF’,*  Graphic  Syntax  •« 
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Ross  article 

User ’ s  Manual 

1 i ne  numbe r 

Term 

Reference 

16 

OK  branch 

NOT  FOUND 

17 

OK  join 

NOT  FOUND 

2  1 

CALL  ON  SUPPORT 

NOT  FOUND 

2  3 

2-1  WAY  HUTTING 

ARROW  NOT  FOUND 

26 

NOTH 

NOT  FOUND 

36 

REF.  EXP.  "DOT" 

NOT  FOUND 

Figure  13.  Graphic  Notations  Unused  by  IDEF, 
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An  additional  graphical  feature  is  used  in  both  the 
Sof tech  and  IDKFq  diagrams  but  not  described  by  1DKF  or  the 
Ross  article,  is  the  use  of  the  slash  (/)  to  separate 
the  forward  and  backward  content  of  double  headed  arrows. 
This  syntax  is  described  in  other  Sof tech  literature 
describing  the  SADT  methodology  (Softech  Inc.,  1976:4-21). 

AFIT  Structured  Analysis  Diagram  Syntax 

A  sampling  of  structured  analysis  diagrams  generated  by 
AFIT  students  and  faculty  found  the  syntax  adopted  by  IDKFq 
is  sufficient  for  performing  requirements  analysis.  None  of 
the  graphic  notations  described  by  Ross  and  unused  by  IDKFq 
were  found  in  the  diagrams  sampled.  For  these  reasons, 
Figure  12  is  also  the  AFIT  syntax. 

Subset,  of  AFIT  Syntax  Implemented 

Figure  14  is  the  subset  of  the  AFIT  structured  analysis 
syntax  that  was  implemented  by  the  tool.  Due  to  the  time 
limitation  for  implementing  the  tool,  some  of  the  low 
priority  constructs  were  not  implemented.  Presented  next 
are  the  reasons  t.he  five  graphical  constructs  were  not 
implemented  by  this  tool. 

Meta-not.es  are  additional  comments  about,  a  structured 
analysis  diagram  and  are  placed  on  the  diagram.  This 
feature  was  not  implemented  because  the  diagrams  must  be 
tied  to  t.he  data  dictionaries  as  much  as  possible. 


Ross  arLic  1  e 
line  numhe  r 


Term 


User ’ s  Manua 1 
Re  I'erence 


1 

BOX 

2-2,3 

2 

ARROW 

2-2,3 

3 

INPUT 

3-26  (FIG) 

3 

OUTPUT 

3-26  (FIG) 

4 

CONTROL 

3-26  (FIG) 

5 

MECHANISM 

3-  1  1 

6 

ACTIVITY  NAME 

2-3,4 

7 

LABEL 

2-3 , 4 

1  2 

BRANCH 

3-9 

1  3 

JOIN 

3-9 

18 

BOUNDARY  ARROW 

3-17 

22 

2 -WAY  ARROW 

3-26  (FIG) 

24 

TUNNEL  ARROW 

2-3 

25 

TO/FROM  ALL 

6-2  1 

27 

FOOTNOTE 

3-26  (FIG) 

29 

SQUIGGLE 

3-26  (FIG) 

30 

C-NUMBER 

2-3 

3  1 

NODE  NUMBER 

2-3 

3  2 

MODEL  NAME 

3-16 

3  3 

I COM  CODE 

4-8 

37 

FACING  PAGE  TEXT 

4-  1 

Figure  11.  Implemented  Graphic  Syntax 


Meta-notes  do  not.  correlate  to  any  data  dictionary  entry. 


According  to  Ross : 


There  is  no  way  that,  information  in  metanotes  can 
participate  in  t.he  informat. ion  content  of  the 
diagrams,  and  therefore  t.hey  should  not  be  used  in 
an  attempt  to  affect,  the  interpretation  of  the 
diagrams  themselves,  but  only  for  mechanical 
operations  regarding  the  diagram’s  physical  format 
or  expression  (Ross,  1977:30). 


Bundle  arifi  spread  were  not  implemented  because  these 
constructs  eari  be  represented  as  a  special  case  of  the 
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Join  and  branch,  res  pec  t  i  ve  1  y  .  Implementing  both  sets  of 

const. ruets  in  Lhe  tool  would  be  a  dupl  ication  of  effort.. 
FEO’s  pictorial ly  highlight  features  and  special  effects  of 
the  diagram.  They  were  not  implemented  by  t.h  i  s  tool  because 
they  do  not  correspond  t.o  any  data  dictionary  entry,  except 
the  description.  The  user  should  attempt  t.o  highlight, 
features  of  the  diagram  in  words  in  the  fac i ng  page  text  of 
the  diagram. 

The  purpose  of  the  Glossary  is  to  define  terms  using 
words  and  pictures.  Again,  because  items  normally  found  in 
the  Glossary  cannot  be  directly  tied  to  the  data  dictionary, 
it  was  not.  implemented. 


Data  Dictionary  Formats 

There  are  two  types  of  data  dictionary  formats,  one  to 
describe  activities  and  one  t.o  describe  data  elements.  For 
this  tool,  the  data  dictionaries  generated  were  of  the 
formats  specified  by  the  AFIT  Software  Development 
Documentation  Guidelines  and  Standards  (llartrum,  1986). 

Figure  15  shows  the  format  for  the  information  inserted 
into  .t  Data  Dictionary  for  Activity.  Figure  16  shows  a 
completed  (- x am p  1  e  of  this  type  of  da t.a  dictionary  entry. 

Figure  17  shows  the  format  for  t.he  information  inserted 
into  a  Data  Dictionary  for  Data  F !  omen  t.  .  Figure  18  shows  a 
completed  example  of  this  typo  of  data  dictionary  entry . 
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NAME  (  o f  an t  i v i ty ) 

TYPE :  ACTIVITY 

PROJECT:  (Project  name) 

NUMBER:  (Node  number  of  this  activity) 

DESCRIPTION:  (Multiple  Lines  allowed) 


1  i  nes 


INPUTS:  (Multiple  lines  al lowed-one  entry/ l i ne ) 

OUTPUTS:  (Multiple  lines  al lowed-one  entry/line 

CONTROLS:  (Multiple  lines  al lowed-one  entry/line) 

MECHANISMS:  (Multiple  lines  al 1  owed -one  entry/ I  inn) 
ALIASES:  (Names  of  aliases,  multiple  lines  alio 

COMMENT:  (Why  is  this  alias  needed?) 

PARENT  ACTIVITY:  (Name  of  parent  activity) 

RELATED  REQUIREMENT  NUMBER:  (Paragraph  number  of 

textual  requirements  statement) 
(Multiple  lines  al lowed-one  entry/line) 


1  owed ) 


VERSION:  (version  of  this  data  dictionary  ent. ry) 

VERSION  CHANCES:  (Why  was  the  last,  version  updated?) 

DATE:  (of  this  entry) 

AUTHOR:  (of  this  entry) 


NAME  :  MAM  HI  LATE  KILLS 

FALK:  AfTil  IT) 

PROJECT:  NETOS 

NIMFiFR:  AIL 

RESLk  1  HT  I  i»S  :  This  activity  handles  all  remote 
requests  to  manipulate  .actual  Liles.  i'his 
includes  printing  local  files,  storing  Local  files 
on  the  MSS ,  and  request i n?  files  from  the  MSS. 

1  SPITS  : 

K  LA  BOARD  I  N  HI  T 
MSGS  A  DAT  \ 

DISK  KILLS 
i )l  T H1  TS  : 

CRT  01  FRIT 
MSGS  N  DATA 
DISK  KILLS 
DOS  h 
)\  FROLS  : 

SELECTION 
MKLHA.N  I  SMS  : 

\ L 1  ASKS  : 

i  N  iMMLN'T  : 

RAREST  ACTIVITY  :  EXEAT’  Ft  REMOTE  FLSLT  I  oN 
RELATED  REQCI  R  FMFNT  STM  HER  :  i.L.i 

vFKSlOS:  1.0 

'.FUSION  CHANGES  : 

DA  FF  :  k/ lit /SI 

A I  TIL  >k  :  T  .  ! ' .  Hart  rum 


i  mire 


Data  Dictionary  for  \  c t 
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NAME:  (of  this  (data  item) 

TYPE:  DATA  ELEMENT 

PROJECT:  (Project  name) 

DESCRIPTION:  (Multiple  lines  allowed) 

DATA  TYPE:  (if  known) 

MIN  VALUE  :  (  i  f  app  1  i  cab  1  ('-mu  1  t  1  pic  I  l  nes  a  I  1  owed  - 
MAX  VALUE :  (  i f  app 1  i cab  1  e-mu  1  I  i p 1 e  I  i nes  a  1  I  owed  - 
RANGE :  (if  applicable) 

VALUES:  (allowable  values,  it'  appropriate  -  mult 

1  i  nt'K  al  lowed- 1  entry  tier  I 
PART  OF:  (parent  data  element  -  multipit'  lint's 

al lowed- 1  entry  per  1 i 
COMPOS  I T I  ON :  ( sub  e 1  emeu ts ,  if  any .  mu  1  t  i p 1 e  I  i 

al  towed  -  1  entry  pe r  1  l 

ALIASES:  (Names  of  aliases,  multiple  lines  all 

WHERE  USED:  (I  DEED  activity  number) 

COMMENT:  (Why  is  this  alias  needed’) 

SOURCES:  (IDEFO  activity  names) 

DESTINATIONS:  ( IDEFO  activity  names) 

RELATED  REQUIREMENT  NUMBER:  (Paragraph  number  o 

textual  requirements  statement 
(Multiple  lines  allowed-one  entry/ line) 


1/1  I  ne  ) 
1/1  i  rie  ) 


ne  ) 
owed  ) 


VERSION:  (version  of  this  data  dictionary  entry ) 

VERSION  CHANGES:  (Why  was  the  last,  version  updated?) 

DATE:  (of  this  entry) 

AUTHOR:  (of  this  entry) 


l  gure 


Format  of  a  Data  Diet  ionarv  tor  Data 
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NAME :  MSGS  &.  DATA 

TYPE:  DATA  ELEMENT 

PROJECT:  NETOS 

DESCRIPTION:  NETOS  messages  and  data,  including  files, 
transferred  around  the  network. 

DATA  TYPE: 

MIN  VALUE: 

MAX  VALUE: 

RANGE : 

VALUES : 

PART  OF: 

COMPOSITION: 

MSGS 

DATA 

ALIASES:  messages  and  data 

WHERE  USED:  A122,  A135 

COMMENT:  Due  to  group’s  inconsistency 
SOURCES : 

MANIPULATE  FILES 
MANIPULATE  FILE  INFORMATION 
DESTINATIONS : 

MANIPULATE  FILES 
MANIPULATE  FILE  INFORMATION 
MANIPULATE  COMMO  LINKS 
RELATED  REQUIREMENT  NUMBER:  1.2. 4.  2 

VERSION:  1.0 

VERSION  CHANGES: 

DATE:  9/13/84 

AUTHOR:  T.C.  Hartrum 


Figure  18.  Data  Dictionary  for  Data 
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taring  Page  I  ext  format 

The  format,  for  the  facing  page  t.ext.  generated  by  this 
tool  was  also  based  on  a  format,  provided  in  AFIT’s  Software' 
Development  Documentation  Guidelines  and  Standards.  The 
AFIT  data  dictionaries  are  designed  to  contain  all  the 
information  provided  in  the  structured  analysis  diagram  and 
its  facing  page  text. .  To  map  the  facing  page  t.ext  to  the 
data  diet  ionary,  the  facing  page  text  must  match  exactly  the 
text,  in  the  "Descr  i  pt.  i  on"  field  of  that  activity’s  data 
dictionary.  The  format  and  rules  for  facing  page  text  are 
shown  in  Figure  19. 


A  heading  is  located  at  the  left  column  and 
consists  of  the  Node  number,  then  two  spaces,  and 
then  the  Title  (exactly  as  given  on  the  diagram). 


Following  the  headings  is  a  section  beginning  with 
"Abstract:,”  then  two  spaces,  followed  by  an 
overview  of  the  diagram.  If  a  parent  diagram  for 
this  diagram  exists,  then  the  text  matches  exactly 
the  description  given  on  the  parent  diagram  facing 
page  text. 


For  each  activity  box  in  the  diagram  and  in  order 
according  to  the  node  number,  a  paragraph  starting 
with  the  node  number,  followed  by  two  spaces,  and  a 
description  of  the  activity  follows  the  abstract. 
This  description  will  match  exactly  the 
"Description"  field  of  the  data  dictionary. 

The  lines  between  the  heading,  the  abstract,  and 
each  activity  paragraph  are  double  spaced. 

The  first  line  of  each  activity  paragraph  is 
indented  5  spaces. 
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Facing  Page  Text  format 
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Appendix  B:  Example  Outputs 


The'  following  pages  contain  example  outputs  of  the 
tool  .  The?  first,  page?  is  an  example?  of  an  SA  diagram 
gene?rated  using  "Make?  Diagram  (Normal)"  selection  .  The? 
second  page?  is  an  example?  of  an  SA  diagram  generated  using 
the  "Make  Diagram  (Side-ways)"  selection.  The  third  page-  is 
an  example?  of  an  Activity  Element  Data  Dictionary  and  the? 
fourth  page?  is  an  example  of  a  Data  Element  Data  Dictionary , 
Finally,  the  fifth  page  is  an  example  of  the?  Facing  Page? 

Te'xt  for  a  diagram. 
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NAMr  :  new  marr 
TYPE  :  DATA  ELEMENT 
PROTECT  •  E'"'c; 
DESCRIPTION  : New  Mail 
the  user  that  includes 
as  well  as  the  body  of 

'T'vpr  • 

MIN  VALUE  : 

MAX  VALUE  : 

RANGE  : 

VALUES  : 

PART  OF  : 

COMPOSITION  : 

ALIASES  : none 
WHERE  USED  : 

COMMENT 
SOURCES  : 

DESTINATIONS  : 


is  a  r.ew  message  generate 
the  appropriate  header  in 
the  message. 


RELATED  REQUIREMENT  NUMBER  : 

VERSION  : 1 . 1 

VERSION  CHANGES  : chanced  "bulliten  board"  to  bb 

DATE  : 11/06/87 
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Abstract :  Provide  Mail  allows  the  user  to  bui 

message,  access  any  message,  and  transmit  any 
message . 

All  This  activity  builds  the  appropriate 
fields  of  the  message. 


A12  This  activity  takes  all  new  mail 
and  bb  reolies  and  sends  them  to  the  appropriate  use 


A13  This  activity  takes  inputs  and  user  files 
parses  user's  commands  to  allow  access  to  his  ma 
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Appendix  C:  File  Format  Definitions 

This  appendix  defines  the  file  format  for  ".gph" 
and  .dbs”  extension  files  generated  by  the  tool. 

".gph"  File  Format 

The  purpose  of  this  file  is  to  store  the  graphical 
information  not  found  in  the  data  dictionary,  but 
is  needed  to  redraw  the  diagram.  Figure  21  is  part  of  a 
".gph"  extension  fi  le  generated  by  the  tool.  The  graphical 
portions  of  each  of  five  graphical  entities  (box,  header, 
squiggle,  footnote,  and  line)  are  represented  in  this  file. 
Tn  this  file,  all  blank  entries  are  noted  with  the  string: 
$$NULI.$$.  The  format  for  each  graphical  entity  is  specified 
in  the  following  paragraphs. 

Box  Entity  Format.  The  activity  box  information  is 
stored  first  in  the  file.  The  information  is  contained  on 
one  line  with  the  line  of  information  beginning  with  the  box 
identification  number,  "1."  Following  this  number  is  the 
screen  coordinates  (x  coordinate  followed  by  the  y 
coordinate)  of  the  lower  Left  corner  of  the  activity  box. 

The  remaining  part  of  the  line  is  treated  as  a  string  and 
constitutes  the  name  of  the  activity  box. 

Header  Entity  Format.  The  project  name  and  diagram 
number  are  the  entities  from  the  header  structure  that  are 
saved  in  this  file.  This  information  is  stored  in  two 


1  ! 2  8  1  77  Add  Dot 

i  228  251  Add  Arrowhead 

1  328  32-1  Add  Tunnel 

1  125  398  Add  Squiggle 

1  5i,l  173  Add  branch 

1  818  548  Add  Join 

2  0-5 
SA  Tool 

3  221  97  207  93  213  99  200  91 

3  803  484  830  458  830  464  639  457 

3  748  527  718  520  755  524  756  517 

3  312  166  276  176  286  167  263  166 

3  504  311  466  325  471  315  153  315 

3  596  384  561  399  569  387  551  386 

3  400  240  369  239  378  243  358  211 

4  139  65  15  526  1 

4  182  66  218  527  2 

4  675  462  501  534  3 

4  193  63  649  418  1 

4  494  84  713  509  5 

10  27  144  75  144  1  512  12  139 

I  1 

$$NULL$$ 

$$NULL$$ 

User  Inputs 

102  75  144  128  144  04-1-1 

$$NULL$$ 

$$NULL$$ 

$$NULL$$ 

$$NULL$$ 


Figure  21.  Example  ”.gph"  File 


1 i nes ,  the  first  line  beginning  with  the  header 
identification  number,  "2".  Following  the  identification 
number  on  the  first  line  is  a  string  that  represents  the 
diagram  number.  The  string  on  the  second  line  represents 
the  project  name. 

Squiggle  Entity  Format.  Following  the  header 
information  is  the  squiggle  information.  Each  squiggle 


ent,  ity  is  described  on  one  line  with  the  first  number  being 


the  squ  l  g g  l  e  i  den  t  i  t*  i  ca  t  ion  numbe r  ,  "  ii  "  .  Following  the 

[(lent  i  t'n'iit  ion  number  are  four  x  ami  y  coo  rd  i  na  t.e  pairs  that 
make  up  t  hie  three  I  i  ne  segments  of  each  squiggle  1  ine. 

Footnote  Frit  i  t.y  Format  .  Fo  i  lowing  the  squ  i  fig  I  e 
informat  ion  in  the  file  is  t.he  footnote  information.  Ranh 
foot  not  i'  on  I  i  t.y  is  dese  r  i  bed  on  one  line  with  the  first, 
number  be  i  ng  the  footnote  identi  filiation  number,  " -1  "  . 

Fol  lowing  the  identification  number  are  two  x  and  y 
coordinate  pairs  representing  the  lower  Left  corner  of  each 
footnote  box.  Following  these  coordinates  is  the  character 
label  f  o  r  bo  t  h  boxes . 

bine  Entity  Format.  The  line  information  is  the  last 
information  stored  in  the  file.  Each  line  segment  is 
described  in  the  file  with  five  lines  .  The  first  line 
begins  with  a  line  identification  number  that  is  greater 
than  or  equal  to  ten.  Following  the  identification  number 
are  two  x  and  y  screen  coordinate  pairs  representing  the 
start  point  and  end  point  of  the  line  segment,  respectively. 
The  next  t.wo  numbers  represent,  first,  the  line’s 
eombinat  ion  of  begin  at.tribut.es,  then  t.he  line’s  combination 
of  end  attributes.  The  final  two  numbers  are  the  x  and  y 
screen  coordinates  of  t.he  line  label,  if  it  exists. 

The  remaining  four  lines  store  the  various  labels  that 
art'  associated  with  a  line  segment.  The  first  of  these 
lines  (second  in  line  ent.it, y  block)  is  the  label  for  t.he 
1  POM  code  that,  may  be  associated  with  the  beginning  of  a  lin 


segment  :  Input.,  Control,  or  Mechanism.  The  second  of 

t  hese  linos  is  the  output.  1  COM  code  associated  w  i  t.h  the  end 
of  a  1  i  ne  segment  .  The  third  of  these  1  i  nes  is  t.he  fO-Abl, 
or  FR0M-AL1,  e  i  re  1  e  label  that,  may  apply  t.o  t.he  1  i  rie  segment. 
The  last  line  is  the  label  that  is  associated  with  t.ho  1  me 
segment.  Again,  if  a  field  is  not  specified  for  a  given 
line  segment,  the  "$$NUbb"  string  is  inserted  into  the  file 

Finally,  all  ".gph"  files  contain  a  "0"  on  the  last 
line  of  the  file  to  signal  that,  the  last  line  has  been 
reco  rded  . 

".dbs  File  Format 

The  purpose  of  this  file  is  to  store  the  data 
dictionary  information  in  a  format  capable  of  being  read  in 
by  the  database  management  tool.  The  file  consists  of  a 
session  header,  a  list  of  activity  data  dictionaries,  and  a 
list  of  data  element  data  dictionaries.  Fach  section  is 
separated  by  separated  by  a  unique  delimiter.  Figure  22  is 
an  outline  of  the  format  for  a  ".dbs"  file.  The  following 
paragraphs  describe  the  format  for  the  session  header  and 
the  format  for  storing  a  field  for  both  types  of  data 
dictionaries. 

Session  Header  Format.  Figure  22  is  an  example'  of  a 
Session  Header,  identifying  each  of  the  needed  fields  and 
the  order  they  must  appear.  Note  that,  the  first  line  may 
have  two  different  character  st. rings.  If  the  diagram  doe's 
not.  contain  sufficient  information  feir  t.hei  dat. abase  manager 


SESSION  I*1  ILK 


#@@BF,G1N«@#  or  $  $  $  $  LOCAL  $  $  $  $  /*Begin  file*/ 

- SKSSION  HEADER - 

###ACTION  TYPE###  /*8egin  activities  list*/ 

@##START##@  /*Begin  an  activity#/ 

- ACTIVITY  DATA  DICTIONARY - 

@##STOP##«  / *  End  of  activity#/ 

o 

o  /*More  activities*/ 

o 

###ACTION  END###  /#End  of  activities*/ 

# # #0B J ECT  TYPE###  /*Begin  data  List*/ 

@##START##@  / *  Beg i n  a  data  item*/ 

- DATA  ELEMENT  DATA  DICTIONARY - 

@##STOP##@  / *  End  of  data  item*/ 

o 

o  /*More  data  items*/ 

o 

###OB JECT  END###  /*End  of  data  items*/ 

#@@END««#  /*End  of  the  file*/ 


Figure  22.  Session  File  Outline 


to  store  and  recall  the  data  dictionary  information, 

"  $$$$LOCAI,$$$$ "  is  inserted  to  make  the  file  incompai  i* 
with  the  database  manager.  If  the  diagram  is  suit' 
complete,  the  ” #@@BEGIN@@# ”  string  is  insert ci  c 
database  manager  will  accept  t.he  fi  I  r  . 

Data  Dictionary  Field  Format  .  It. 
an  activity  element,  data  diet  i<.n  i> 


element  data  dictionary  i * •  r • 


specified  by  seven  lines  in  the  file. 


Figure  24  is  an 


example  of  how  one  field  is  stored. 


#@#HEADER  BEGIN#®# 


SESSION  CONTAINS  ALL  NEW 

RECS  / *  SESS ION  ID*/ 

SADT 

/♦TOOL  ID  */ 

SDI 

/♦PROJECT  NAME*/ 

REQ 

/♦PHASE*/ 

BOTH 

/ *TYPE  OF 

DATA  (also  ACT  or  OBJ)*/ 

Wed  Nov  19  04 : 

16:56  1987 

/♦START  TIME*/ 

Wed  Nov  19  04 : 

18:40  1987 

/♦STOP  TIME*/ 

Add  Dot 

ACT 

/♦ENTITY  LIST*/ 

Add  Arrowhead 

ACT 

. 

/*Name  Type  */ 

. 

/*  ACT  =  ACTIVITY  */ 

Add  Squiggle 

ACT 

/*  OBJ  =  DATA  */ 

User  Inputs 

* 

OBJ 

• 

• 

User  Outputs 

OBJ 

#@#HEADER  END#®# 


Figure  23.  Example  Session  Header 
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*** 
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File  Format 


/ *DATA  NAME*/ 

/♦FIELD  LENGTH*/ 
/*MULTI-LINE  ?*/ 

/ *  NUMBER  OF  FIELDS*/ 
/♦DIRECTION — N/A*/ 

/ *  I COM  TYPE  */ 
/♦FIELD  CONTENTS*/ 


Each  field  of  the  data  dictionary  has  a  defined  DATA 


NAME-;  according  to  the  relational  schema  defined  for  these 
data  dictionaries.  The  database  manager  does  not  require 
the  field  information  to  appear  in  any  order,  however,  this 
tool  keeps  the  order  the  same  as  that  for  the  "human- 
readable"  format  of  the  data  dictionary.  The  following  are 
the  DATA  NAME’s  saved  in  an  activity  element  data 
d  icl.i  onary : 

1 .  aname 

2 .  number 

3.  description 

4  .  d i name 

5 .  a 1 iasname 

6 .  comment 

7 .  re  ference 

8 .  re  f  type 

9.  version 

10.  date 

1 1 .  author 

The  following  are  the  DATA  NAME’S  that  are  saved  in  a  data 
element  data  dictionary: 

1 .  d i name 

2 .  description 

3 .  datatype 

4 .  low 

5 .  hi 

6 .  span 

/ .  value 

8 .  hidiname 

9 .  1 od i name 

10.  a 1 i asname 

1 1 .  comment 

1  2  .  wiiereused 

1  3 .  vers i on 

1  4  .  date 

1  5  .  author 


/'/vVv'/Vv'/V  _ 


>.  s.  . 
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Append i x  D : 


Configuration  Guide 


The  purpose  of  this  appendix  is  to  specify  the 
procedure  for  generating  the  executable  file,  "SAtooi . "  Th 
execut.able  file  for  this  tool  was  generated  by  using  the 
UNIX  "make"  facility.  Using  this  method,  changes  to  the 
source  files  are  tracked  and  recompiled  as  necessary  before 
linking  the  files  together.  If  changes  to  t.he  globals.h 
files  are  made,  the  "make"  facility  does  not  know  to 
recompile  the  affected  source  fiLes,  it  is  the  programmer’s 
responsibility.  Figure  25  is  a  copy  of  the  file  called 
"Makefile."  To  use  this  file,  the  command  "make"  is  typed 
at  the  system  prompt,  causing  any  needed  compilations  and 
then  linking  of  the  files. 

OBJECTS  =  raain.o  datadict.o  messages. o 
boxfuncl.  ions.o  headerf  unct  ions  .  o  ed  i  tboxf  unc  .  o 
mi  sc f unc t i ons . o  add  1 i ne . o  figures. o  endfuncs.o 
find.o  mo  re  1 i ne f uncs . o  linelabel.o  moreddfuncs  o 
ddsearch f uncs . o  save f uncs. o  fptfuncs.o  sqglefuncs.o 
fnot.efuncs.o  raoresave.o  screendump.o  readfuncs.o 
sess i on . o 

HEADERS  =  globals.h 
ALL  -  sad 
C FLAGS  =  -0 

LIBS  -  -lsuntool  -lsunwindow  - 1  pixrect.  -lm 
sad  :  $( OBJECTS) 

cc  $  (  CFLAGS  )  $(  OBJECTS)  $  (  1. 1  BS  )  -o  SAtooi 


Figure  25  . 


Makefi le  Format 


Appendix  E:  Summary  Paper 


Introduct ion 


The  requirements  analysis  phase  of  the  software  life 
cycle  is  an  important  one.  The  Department  of  Electrical  and 
Computer  Engineering  at  the  Air  Force  Institute  of 
Technology  (AFTT)  has  established  an  analysis  methodology 
for  this  phase  of  the  software  Life  cycle  that  consists  of 
using  structured  analysis  (SA)  diagrams  and  a  data 
dictionary.  This  paper  describes  the  integration  of  these 
two  techniques  into  a  computer  automated  tool  for  the 
purpose  of  improving  the  software  requirements  analyst’s 
produc t i v i ty . 

An  analyst's  productivity  can  be  improved  because  of 
two  significant  reasons.  First,  several  pieces  of 
information  are  needed  for  both  an  SA  diagram  and  a  data 
dictionary.  Separate,  these  two  methods  create  a 
significant  duplication  of  effort  to  enter  the  information 
twice.  The  integration  of  the  two  methods  eliminates  the 
extra  effort.  Second,  the  analyst  is  freed  from  much  of  the 


effort  needed  to  create  the  diagram  by  hand  (e.g.  drawing 
straight  lines).  This  freedom  is  received  by  using  a  tool 
tailored  for  this  specific  purpose. 


Integrating  two  approaches  into  one  tool  divides  the 


tool  into  two  natural  components:  the  SA  diagrams  and  the 

data  dictionaries.  This  section  describes  each  of  the 
components . 

SA  Diagrams.  The  SA  diagrams  use  a  graphical  language 
that  is  derived  from  the  Structural  Analysis  Design 
Technique  ( SADT )  ( SADT  is  a  trademark  of  SofTech,  Inc.),  and 

are  accompanied  by  facing  page  text  to  assist  in  the 
understanding  of  the  diagram.  Rectangular  boxes  and  arrows 
are  the  primary  graphical  constructs  used  in  an  SADT 
diagram.  The  boxes  represent  the  decomposition  of  the  parts 
of  the  system  being  analyzed.  The  arrows  are  used  to 
describe  how  the  boxes  interface  between  each  other  on  the 
diagram.  The  graphical  language  consists  of  English  text  to 
label  the  diagram  and  40  graphical  constructs  to  describe 
relationships  (SofTech  Inc.,  1976:4-4). 

SofTech  proposed  that  the  SADT  methodology  could  be 
applied  to  many  types  of  problems  in  addition  to  software 
requirements  analysis  (Ross,  1977:17).  The  U.S.  Air  Force 
Program  for  Integrated  Computer  Aided  Manufacturing  (It'AM) 
adopted  a  version  of  SADT  from  SofTech  and  called  it  ICAM 
Definition  Method  Zero  or  IDEFq.  Now  the  Air  Force  uses 
t.his  similar  structured  methodology  to  improve  the 
communication  of  people  who  use  computers  to  improve 
manu  fac  luring  produc  t.  i  v  i  ty  . 


h  -  J 


&&&&& 


y  / 


Data  Dictionaries.  The  purpose  of  a  data  dictionary  is 


to  manage  and  document  data.  According  to  Lefkovits 


(befkovits,  1977),  using  data  dictionaries  provide  many 


benefits  including:  reduction  of  administrative  effort., 


reduction  of  data  redundancy,  and  reduction  of  system 


development,  costs.  Regarding  software  requirements 


analysis,  l.eong-IIong  and  Flagman  suggested  that,  data 


dictionaries  are  an  excel  lent  vehicle  for  maintaining 


documentation.  Furt.he  rraore ,  they  recommended  that  the  data 


dictionary  system  for  producing  documentation  be  automated 


to  reduce  the  monotony  of  the  task.  ( Leong  Hong  and  Plagman, 


1 982 : 50 ) 


Requirements  Definition 


Requirements  for  this  tool  were  based  on  previous 


research  at  AFIT.  A  data  dictionary  editor  existed  that 


allows  the  user  t.o  type  and  save  the  information  on  a 


workstation  and  i ndependen 1. 1  y  store  the  information  in  a 


relational  database.  Research  accomplished  in  parallel  with 


the  tool  development  deve loped  a  data  manager  to  save  and 


recall  information  in  the  database.  That  effort  specified  a 


standard  file  format  for  accessing  data  dictionary 


information  general  ed  by  t.he  tool. 


A  prototype  tool  to  integrate  SA  diagrams  and  data 


dictionaries  was  built  at  AFIT  in  1986.  This  prototype 


implemented  a  small  subset  of  the  entire  SA  language  syntax 


used  by  SADT  and  IDEFn.  To  extend  this  prototype  effort,  it 


was  necessary  to  nxiiminc  the  SADT  and  I  DFFq  graphic  syntaxes 
and  identify  a  necessary  and  sufficient  language'  for 
i rap  1  omen  tat i on  of  this  tool. 

The'  prototype  as  well  as  this  tool  were  required  to 
carefully  consider  the  huraan/compute r  interface  aspect,  of 
the  tool  because  of  the  interactive  nature  of  the  program. 
Specifically,  the?  following  rules  for  de ve  1  op i  ng 
human/computer  interfaces  were  considered  in  its  design: 


1.  Keep  the  user  motivated. 

2.  Break  the  input  process  int.o  parts,  to  achieve 
" psycho  1 og i ca 1  e 1 osure  .  " 

B.  Provide  positive  feedback  to  t ho  user. 

4.  Minimize  memorizal ion  required  by  the  user. 

5 .  Provide  a  visually  pleasing  display  on  the 
so  r< -on  . 

6.  Minimize  the  response  time  of  the  t.oo  l  , 


Figure  1.  Ilumari/Computor  Interface  Requirements 
Source:  (llrschelcr,  1  !)H6  :  2  1  )  . 

Final  I;.,  par!  of  the  tool’s  function  was  t.o  provide 
hardcopy  outputs  >f  the  various  products  maintained  by  t he 
tool.  Therefore,  it.  was  required  that  the  tool  implement  a 
(m  ans  t.o  produce  the  SA  diagram,  the  accompanying  taxiing 


page  text.,  and  the  data  dictionaries  generated  by  the  t.oo  I 


Description  of  the  Tool 


I 

V. 


Hardware  Decisions.  SUN  workstations  were  chosen 
because  they  met  several  hardware  requirements.  Six  SUN 
workstations  were  available,  each  having  a  mouse  input 
device  for  manipulating  the  graphical  constructs  of  the  SA 
diagram.  Fach  SUN  has  a  large  display  monitor  to 
accommodate  an  uncluttered  user  interface.  Finally,  all  the 
SUN  workstations  are  tied  to  the  AFIT  computer  network, 
important  for  the  transporting  of  data  dictionary 
i nf ormat i on . 

Software  Decisions.  Based  on  the  availability  of  the 
SunView  package  and  the  desire  to  use  certain  software 
modules  from  the  prototype  again,  it  was  decided  to  proceed 
with  the  SunView  package.  Also,  the  tool  was  implemented  in 
0  because  SunView  supports  this  language. 

Human/Computer  Interface.  The  design  of  an  acceptable 
human/computer  interface  was  of  primary  importance  in  this 
effort . 

The  screen  layout  consisted  of  five  areas  or  windows  as 
shown  in  Figure  2:  the  Input  Window,  the  Message  Window, 

the  Selection  Window,  the  Diagram  Window,  and  the  Data 
Dictionary  Window.  The  Input  Window  is  where  the  user 
enters  all  text  labels  for  the  SA  diagram.  In  the  Message 
Window,  the  user  receives  instructions,  feedback,  and  help 
messages.  The  Selection  Window  provides  a  mechanism  for 


choosing  one  of  four  menus  of  actions  needed  to  bu i Id  an  SA 


diagram  and  data  dictionaries-  The  Diagram  Window  shows  the 
current  SA  diagram  and  the  Data  Dictionary  Window  is  where 
data  dictionary  information  not  derived  from  the  diagram  is 
entered  by  the  user. 


SA  <A[)  nun 


INPUT :  DISABLED 


MESSAGE:  WELCOME,  Plats*  maks  a  sslsction 


iUTHOR • 

I0A7E  : 

IREADER 

PROJECT 

IrEV  : 

iDATE 

Figure  2.  SAtooi  Screen  Layout 


*  •  *  Ov*  h*  .  ■» 
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A  menu  system  was  selected  because  it  solved  several 
rules  for  a  good  user  interface.  The  menu  selections  are 
grouped  according  to  the  major  function  they  provide: 
editing  a  diagram,  editing  a  data  dictionary,  displaying 
facing  page  text,  saving  the  diagram,  or  executing  system 
functions  (e.g.  changing  the  working  directory).  Within 
each  grouping,  the  menu  selections  are  structured  in  a 
hierarchical  manner  that  matches  the  functional 
decomposition  of  the  tool. 

Data  Files.  The  tool  is  capable  of  producing  five  data 
files,  two  that  save  raw  data  (graphics  and  data  dictionary 
information)  and  three  that  save  output  products  of  the' 
tool.  Each  file  has  a  unique  file  extension. 

The  first  two  files  save?  the  raw  data  when  the  "save" 
menu  option  is  selected.  The  first  one  contains  graphics 
information  and  is  labeled  with  a  ”.gph"  extension.  The 
second  contains  the  data  dictionary  information  in  a  format 
readable  by  the  database’s  data  management,  system.  This 
file  is  labeled  with  a  ".dbs"  extension. 

The  remaining  three  fi  1  os  are  generated  at,  the  opt  ion 
of  t  hi  user.  The  facing  page  text,  for  a  diagram  is  stored 
in  an  ASCII  file  with  a  " . fpt"  extension.  The  data 
diet  ionaries  associated  w  i  t.h  a  diagram  may  be  saved  in  a 
file  with  a  "  .  dd  ”  extension  appended  to  the  fill'  name  . 


These  can  he  printed  on  any  standard  line  printer.  Finally, 
a  copy  of  the  diagram  on  the  screen  may  be  saveci  in  a  file 
with  a  ".dmp”  extension  which  is  in  a  SUN  rasterfile  format 
and  must  be  printed  by  a  printer  that  supports  this  format.. 

Fva  1  uat.  ion 

After  designing  and  implementing  the  tool,  it  was  made 
available  to  two  graduate  level  software  engineering  classes 
for  use  and  evaluation.  Thirty-three  students  were  assigned 
to  make  one*  diagram  using  the  tool  and  to  complete  a 
quantitative  evaluation  of  t.he  tool  based  on  that 
experience.  On  a  scale  from  -1.00  (maximally  dissatisfied) 
t.o  +1.00  (maximally  satisfied),  t.he  user  scores  averaged 
0.295.  The  scores  ranged  from  -0.182  to  .682  with  a 
standard  deviation  from  the  mean  of  0.291.  On  the  average, 
the  evaluators  used  the  tool  about  138  minutes  before 
completing  the  evaluation. 

Cone  1  us i ons 

The  purpose  of  this  thesis  was  to  integrate  the 
structured  analysis  and  data  dictionary  document. at.  i  on 
methodologies  into  a  computer  automated  tool  to  improve  the 
requirements  analyst’s  productivity.  The  progress  of  this 
effort,  was  h  l  gh  1  i  gh  fed  by  the  foil  ow  i  ng  mi  lest  ones  : 


Analysis  previous  efforts  including  the 
reusability  of  software  from  the  prototype. 

Identification  of  the  necessary  and  sufficient 
graphic  syntax  implemented  by  the  tool. 

Successful  design  and  implementation  of 
tool’s  software. 

Evaluation  of  the  tool’s  usefulness  using 
questionnaires  and  statistical  methods. 
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Appendix  K:  Requirement.  Analysis  Diagrams 

The  following  pages  contain  the  SA  diagrams  for  the 
requirements  analysis  done  for  this  tool. 
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A1  Create  SA  Diegraae 

Abstract:  Craata  3A0T  Diagrase  gathers  tha  uaar  inputs  ana  convarta  than  into 

graphical  information  representing  tha  diagram.  Throughout  tha  procaaa,  tha 
uaar  la  Informed  of  prograaa  through  updataa  on  tha  CRT  acraait.  Tha  uaar  Bay 
also  uaa  an  existing  /lla  of  uaar  inputs  to  ganarata  a  diagraa.  Data  structures 
ara  craatad  from  which  inputs  to  tha  data  dictionaries  aay  ba  gatharad. 

All  Provide  "tar  Choices  takes  tha  uaar *  a  requests  and  Oatarainaa  tha 
appropriata  action  to  take.  This  procaaa  continues  until  tha  uaar  explicitly 
raquaata  to  quit. 

AIT  Add  to  Diagraa  takas  tha  user's  request  of  graphical  entitles  to  add  to 
tha  diagraa  and  updataa  tha  currant  diagraa.  Tha  update  la  Bade  available  f or 
data  dictionary  updataa.  Also,  tha  uaar  is  kept  aoraaat  of  prograaa  through  tna 
uaa  of  diagraa  updataa  or  tna  screen,  error  aaaaagaa.  ane  prompts. 

A13  Edit  Existing  Diagram  takas  tha  uaar ' a  request  to  change  tha  currant 
diagraa  and  carries  out  tha  function  according  to  tha  AFIT  SA  syntax.  Tha 
change  is  aada  aval  labia  for  data  dictionary  updates.  Also,  tha  user  la  kept 
aoraaat  of  tha  prograaa  by  updating  tha  diagraa  on  tha  screen,  error  aaaaagaa, 
and  proapta. 


Aid  Provide  Input/Output  takas  tha  uaar'a  raquaata  to  read  and  save  f 1 1 a 
and  perforaa  tha  appropriata  operation.  In  tha  case  of  a  read,  tha  activity 
attaapta  to  load  an  existing  file.  Tha  uaar  monitors  tha  status  of  tha 
operation  through  acraan  updataa,  error  aaaaagaa.  ana  proapta. 
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Abstract:  Craata  OD  takaa  tha  graphical  inforaation  partintnt  to  tha  data 
dictionary  (activity  or  data}  along  vith  uaar  inputs  to  eraata  tha  appropriata 
data  dictionary  according  to  tha  AFIT  data  dictionary  foraat.  Tha  atatua  of  tha 
procaaa  la  taintaintd  on  tha  CRT. 


A2I  Sa 1  act  Entity  apacifiaa 
dictionary  to  ba  eraatad. 
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A 22  Gathar  Input*  gat*  tha  daacription  and  inputs  fro* 
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given  tha  option  to  aava.  Tha  uaar  controls  and  aomtora  tha  atatua  of  tha 
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A3  Craata  Facing  Pag#  Taut 
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A  computer  tool  was  designed  ana  implemented  tnat  integrated  two 
approaches  for  documenting  software  requirements  analysis,’  structured 
I  analysis  (S A)  diagrams  and  data  dictionaries.  The  tool  provides  the 
j  provides  the  requirements  analyst  with  an  environment  for  creating  the 
SA  diagrams  and  entering  parts  of  the  data  dictionary.  The  tool  derives 
tne  remaining  data  dictionary  information  from  the  diagram. 

I  background  information  is  provided  on  existing  structured  analysis 

•-  teenniques ,  data  dictionary  uses,  and  on  huiman  computer  interface  design 
n  issues. 

|  A  graphic  SA  syntax  was  derived  from  existing  SA  techniques  and  tne 

J  data  dictionary  formats  were  specified  by  previous  work  at  * AFIT . 

•I-  Requirements  for  the  human  computer  interface  as  well  as  the  functional 
i.  aspects  of  the  tool  are  discussed.  A  summary  of  the  design  decisions  made 
I  are  also  presented. 


nZO  DISTRIBUTION  .  AVAILABILITY  Of  ABSTRACT  21  ABSTRACT  SECURITY  CLASSIFICATION 

□  unclassified iunlimited  KXsame  as  rpt  □  dtic  users  Unclassified 


>  OD  Form  1473,  JUN  86 

K’ 


SECURITY  CLASSIFICATION  Of  this  PAGE 


Previous  editions  are  obsolete 


19.  Abstract 


The  tool  was  used  and  evaluated  by  more  than  35  graduate  level 
software  engineering  students.  The  stuoents  evaluated  the  tool  using  a 
standard  questionnaire  developed  at  AFIT  for  this  purpose.  The  responses 
were  comoiled  and  analyzed  using  statistical  methods  and  are  also  presented 


